Kembridžo universiteto mokslininkai paskelbė metodą, kaip tyliai įterpti kenkėjišką kodą į recenzuojamą šaltinio kodą. Parengtas atakos metodas (CVE-2021-42574) pateikiamas pavadinimu Trojan Source ir yra pagrįstas teksto formavimu, kuris kompiliatoriui/vertėjui ir kodą žiūrinčiam asmeniui atrodo skirtingai. Metodo pavyzdžiai demonstruojami įvairiems kompiliatoriams ir interpretatoriams, tiekiamiems C, C++ (gcc ir clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go ir Python.
Metodas pagrįstas specialių Unicode simbolių naudojimu kodo komentaruose, kurie keičia dvikrypčio teksto rodymo tvarką. Tokių valdymo simbolių pagalba kai kurios teksto dalys gali būti rodomos iš kairės į dešinę, o kitos – iš dešinės į kairę. Kasdienėje praktikoje tokius valdymo simbolius galima naudoti, pavyzdžiui, į failą įterpti kodo eilutes hebrajų arba arabų kalbomis. Bet jei vienoje eilutėje sujungsite eilutes su skirtingomis teksto kryptimis, naudodami nurodytus simbolius, teksto dalys, rodomos iš dešinės į kairę, gali persidengti esamą įprastą tekstą, rodomą iš kairės į dešinę.
Naudodami šį metodą, galite pridėti prie kodo kenkėjišką konstrukciją, bet tada padaryti tekstą su šia konstrukcija nematomą peržiūrint kodą, pridėdami toliau pateiktą komentarą arba pažodinius simbolius, rodomus iš dešinės į kairę, o tai visiškai sukels ant kenkėjiško įterpimo dedami skirtingi simboliai. Toks kodas išliks semantiškai teisingas, tačiau bus interpretuojamas ir rodomas skirtingai.
Peržiūrėdamas kodą kūrėjas susidurs su vaizdine simbolių tvarka ir šiuolaikinėje teksto rengyklėje, žiniatinklio sąsajoje ar IDE matys neįtartiną komentarą, tačiau kompiliatorius ir vertėjas naudos loginę simbolių tvarką ir apdorokite kenkėjišką įterpimą taip, kaip yra, nekreipdami dėmesio į dvikryptį tekstą komentaruose. Problema paliečia įvairius populiarius kodo redaktorius (VS Code, Emacs, Atom), taip pat sąsajas, skirtas peržiūrėti kodą saugyklose (GitHub, Gitlab, BitBucket ir visi Atlassian produktai).
Yra keletas būdų, kaip naudoti metodą kenkėjiškiems veiksmams įgyvendinti: pridėti paslėptą „grįžimo“ išraišką, kuri lemia, kad funkcija bus baigta anksčiau laiko; komentuoti išraiškas, kurios paprastai būtų matomos kaip tinkamos konstrukcijos (pavyzdžiui, norint išjungti svarbius patikrinimus); priskiriant kitas eilutės reikšmes, dėl kurių nepavyksta patvirtinti eilutės.
Pavyzdžiui, užpuolikas gali pasiūlyti pakeitimą, į kurį įtraukta eilutė: if access_level != "user{U+202E} {U+2066}// Patikrinkite, ar admin{U+2069} {U+2066}" {
kuris peržiūros sąsajoje bus rodomas taip, tarsi prieigos_lygis != „vartotojas“ { // Patikrinkite, ar admin.
Be to, buvo pasiūlytas kitas atakos variantas (CVE-2021-42694), susijęs su homoglifų, panašių išvaizdos, bet skirtingos reikšmės ir skirtingų unikodo kodų simbolių naudojimu (pavyzdžiui, simbolis „ɑ“ primena „ a“, „ɡ“ - „g“, „ɩ“ - „l“). Panašūs simboliai kai kuriomis kalbomis gali būti naudojami funkcijų ir kintamųjų pavadinimuose, siekiant suklaidinti kūrėjus. Pavyzdžiui, gali būti apibrėžtos dvi funkcijos, kurių pavadinimai yra neatskiriami, kurios atlieka skirtingus veiksmus. Be išsamios analizės iš karto neaišku, kuri iš šių dviejų funkcijų yra vadinama konkrečioje vietoje.
Saugumo sumetimais rekomenduojama, kad kompiliatoriai, interpretatoriai ir surinkimo įrankiai, palaikantys unikodo simbolius, parodytų klaidą arba įspėjimą, jei komentaruose, eilučių literaluose arba identifikatoriuose, kurie keičia išvesties kryptį, yra nesusietų valdymo simbolių (U+202A, U+202B, U +202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E ir U+200F). Tokie simboliai taip pat turėtų būti aiškiai uždrausti programavimo kalbos specifikacijose ir turėtų būti gerbiami kodų rengyklėse ir saugyklų sąsajose.
1 priedas: GCC, LLVM/Clang, Rust, Go, Python ir binutils yra paruoštos pažeidžiamumo pataisos. „GitHub“, „Bitbucket“ ir „Jira“ taip pat išsprendė problemą. Vykdomas „GitLab“ taisymas. Probleminiam kodui nustatyti siūloma naudoti komandą grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/ šaltinis
2 priedas: Russ Cox, vienas iš Plan 9 OS ir Go programavimo kalbos kūrėjų, kritikavo pernelyg didelį dėmesį aprašytam atakos metodui, kuris jau seniai žinomas (Go, Rust, C++, Ruby) ir nebuvo vertinamas rimtai. . Cox teigimu, problema daugiausia susijusi su teisingu informacijos atvaizdavimu kodų rengyklėse ir žiniatinklio sąsajose, kurias galima išspręsti peržiūros metu naudojant tinkamus įrankius ir kodo analizatorius. Todėl užuot atkreipus dėmesį į spekuliacines atakas, būtų tikslingiau sutelkti dėmesį į kodo ir priklausomybės peržiūros procesų tobulinimą.
Ras Cox taip pat mano, kad kompiliatoriai nėra tinkama vieta problemai išspręsti, nes uždraudus pavojingus simbolius kompiliatoriaus lygiu, lieka didžiulis įrankių sluoksnis, kuriame šių simbolių naudojimas išlieka priimtinas, pavyzdžiui, kūrimo sistemos, surinkėjai, paketų tvarkyklės ir įvairūs konfigūracijos analizatoriai bei duomenys. Kaip pavyzdys pateikiamas Rust projektas, kuris uždraudė apdoroti LTR/RTL kodą kompiliatoriuje, bet nepridėjo pataisymo į Cargo paketų tvarkyklę, leidžiančią panašią ataką per Cargo.toml failą. Panašiai tokie failai kaip BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml ir követelmények.txt gali tapti atakų šaltiniais.
Šaltinis: opennet.ru