Hulumtarët nga Universiteti i Kembrixhit publikuan një teknikë të fshehtë për vendosjen e kodit të dëmshëm në tekstet e rishikuara. Metoda e përgatitur e sulmit (CVE-2021-42574) paraqitet me emrin Trojan Source dhe bazohet në formimin e një teksti që duket ndryshe për kompilatorin/interpretorin dhe njeriun që shikon kodin. Shembujt e përdorimit të metodës janë demonstruar për kompilatorë dhe interpretorë të ndryshëm që ofrohen 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 simboleve të veçanta Unicode në komentet e kodit, të cilat ndryshojnë rendin e shfaqjes së teksteve me drejtim të dyfishtë. Me ndihmën e këtyre simboleve kontrolluese, disa pjesë të tekstit mund të shfaqen nga majtas në djathtas, ndërsa të tjera nga djathta në majtas. Në praktikën përditshme, këto simbole kontrolluese mund të përdoren, për shembull, për të futur në një skedar me kod relevante në hebraisht ose arabisht. Por, nëse kombinoni simbolet me drejtim të ndryshëm në një linjë, përmes simboleve të caktuara, fragmente të 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ë shtoni një strukturë të dëmshme, por pastaj ta bëni tekstin me këtë strukturë të padukshëm gjatë shikimit të kodit, përmes shtimit në një koment që pason ose brenda literalit të simboleve që shfaqen nga djathta në majtas, që do të çojë në mbivendosjen e simboleve krejtësisht të tjera mbi insertin e dëmshëm. Ky kod do të mbetet semantikisht korrekt, por do të interpretohet dhe shfaqet ndryshe.
Gjatë procesit të rishikimit të kodit, zhvilluesi do të përballet me rendin vizual të shfaqjes së simboleve dhe do të shohë në një redaktues teksti modern, ndërfaqe web ose IDE një koment që nuk ngjall dyshime, por kompilatori dhe interpreatori do të përdorin rendin logjik të simboleve dhe do ta trajtojnë insertin e dëmshëm ashtu siç është, pa u marrë parasysh me tekstin me drejtim të dyfishtë në komentar. Problemi është i pranishëm në redaktorët e kodit të njohur (VS Code, Emacs, Atom), si dhe në interface-t për shikimin e kodit në repositorë (GitHub, Gitlab, BitBucket dhe të gjithë produktet e Atlassian).
Dalin disa metoda për të përdorur metodën për të realizuar veprime të dëmshme: shtimi i një shprehjeje të fshehtë 'return', që çon në përfundimin e ekzekutimit të funksionit para kohe; komentimi i shprehjeve, të cilat, normalisht, duken si konstrukte të vlefshme (për shembull, për të çaktivizuar kontrolle të rëndësishme); caktimi i vlerave të tjera string, të cilat çojnë në dështimin e kontrollit të string.
Për shembull, një sulmues mund të propozojë një ndryshim që përfshin rreshtin: if access_level != 'user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}' {
cila do të shfaqet në ndërfaqe për rishikim si if access_level != 'user' { // Check if admin
SĂ« bashku me kĂ«tĂ«, Ă«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 qĂ« kanĂ« kuptime tĂ« ndryshme 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Ă« bĂ«hen dy funksione me emra tĂ« pandashĂ«m, duke realizuar veprime tĂ« ndryshme. Pa njĂ« analizĂ« tĂ« detajuar, nuk Ă«shtĂ« e lehtĂ« tĂ« kuptohet se cili nga kĂ«to dy funksione Ă«shtĂ« thirrur nĂ« njĂ« vend tĂ« caktuar.
Si një masë mbrojtjeje, rekomandohet që të implementohen në kompajlerë, interpretorë dhe mjete ndërtimi që mbështesin simbolet Unicode, dalja e një gabimi ose paralajmërimi nëse ka simbole kontrolli të paç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) në komentet, literalet string ose identifikuesit. Simbole të tilla gjithashtu duhet të ndalohen shprehimisht në specifikimet e gjuhëve të programimit dhe duhet të merren parasysh në redaktorët e kodit dhe ndërfaqet për punë me repositorët.
Shtesa 1: Korrigjimet që eliminojnë dobësitë janë përgatitur për GCC, LLVM/Clang, Rust, Go, Python dhe binutils. Problemi gjithashtu është zgjidhur nga GitHub, Bitbucket dhe Jira. Në procesin e përgatitjes është një korrigjim për GitLab. Për të identifikuar kodin problematik, është propozuar përdorimi i komandës: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/source
Shtesa 2: Ras 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ë e njohur prej kohësh (Go, Rust, C++, Ruby) dhe nuk është marrë seriozisht. Sipas Cox, problemi kryesor lidhet me saktësinë e paraqitjes së informacionit në editorët e kodit dhe ndërfaqet web, i cili zgjidhet duke përdorur mjete dhe analizatorë të saktë të kodit gjatë rishikimeve. Prandaj, në vend që të tërhiqet vëmendja ndaj sulmeve teorik, do të ishte më e drejtë të fokusohemi në përmirësimin e proceseve të rishikimit të kodit dhe varësive.
Ras Cox gjithashtu mendon se kompajlerët nuk janë vendi ku duhet të zgjidhet problemi, pasi duke ndaluar simbolet e rrezikshme në nivelin e kompajluesit mbetet një grup i madh mjetesh ku përdorimi i këtyre simboleve të mbetet i lejueshëm, siç janë sistemet e ndërtimit, assemblers, menaxherët e paketave dhe një sërë parserash për konfigurimin dhe të dhënat. Për shembull, projekti Rust ndaloi përpunimin e kodit LTR/RTL në kompajler, por nuk shtoi një rregullim në menaxherin e paketave Cargo, i cili lejon kryerjen e një sulmi të ngjashëm përmes skedarit Cargo.toml. Po ashtu, burimet e sulmeve mund të jenë skedarë të tillë si BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml dhe requirements.txt.
Burimi: opennet.ru
