Vedci z Cambridgeskej univerzity zverejnili techniku tichého vkladania škodlivého kódu do recenzovaného zdrojového kódu. Pripravená metóda útoku (CVE-2021-42574) je prezentovaná pod názvom Trojan Source a je založená na vytváraní textu, ktorý vyzerá inak pre kompilátora/interpreta a pre osobu, ktorá si kód prezerá. Príklady metódy sú demonštrované na rôznych kompilátoroch a interpreteroch dodávaných pre C, C++ (gcc a clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go a Python.
Metóda je založená na použití špeciálnych znakov Unicode v komentároch kódu, ktoré menia poradie zobrazenia obojsmerného textu. Pomocou takýchto riadiacich znakov je možné niektoré časti textu zobraziť zľava doprava, zatiaľ čo iné - sprava doľava. V každodennej praxi sa takéto riadiace znaky dajú použiť napríklad na vloženie riadkov kódu v hebrejčine alebo arabčine do súboru. Ak však skombinujete riadky s rôznymi smermi textu v jednom riadku pomocou špecifikovaných znakov, pasáže textu zobrazené sprava doľava môžu prekrývať existujúci bežný text zobrazený zľava doprava.
Pomocou tejto metódy môžete do kódu pridať škodlivú konštrukciu, ale potom text s touto konštrukciou zneviditeľniť pri prezeraní kódu pridaním nasledujúceho komentára alebo do doslovných znakov zobrazených sprava doľava, čo povedie k úplnému na zlomyseľnom vkladaní sa prekrývajú rôzne znaky. Takýto kód zostane sémanticky správny, ale bude sa interpretovať a zobrazovať odlišne.
Pri kontrole kódu bude vývojár konfrontovaný s vizuálnym poradím znakov a v modernom textovom editore, webovom rozhraní alebo IDE uvidí nepodozrivý komentár, ale kompilátor a interpret použije logické poradie znakov a spracovať škodlivé vloženie tak, ako je, bez toho, aby ste venovali pozornosť obojsmernému textu v komentároch. Problém sa týka rôznych populárnych editorov kódu (VS Code, Emacs, Atom), ako aj rozhraní na prezeranie kódu v repozitároch (GitHub, Gitlab, BitBucket a všetky produkty Atlassian).
Existuje niekoľko spôsobov, ako použiť metódu na implementáciu škodlivých akcií: pridanie skrytého výrazu „návrat“, ktorý vedie k dokončeniu funkcie v predstihu; komentovanie výrazov, ktoré by za normálnych okolností boli viditeľné ako platné konštrukcie (napríklad na zakázanie dôležitých kontrol); priradenie iných hodnôt reťazca, ktoré vedú k zlyhaniam overenia reťazca.
Útočník môže napríklad navrhnúť zmenu, ktorá obsahuje riadok: if access_level != "user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}" {
ktorý sa zobrazí v rozhraní kontroly ako if access_level != “user” { // Skontrolujte, či je admin
Okrem toho bol navrhnutý ďalší variant útoku (CVE-2021-42694), ktorý súvisí s použitím homoglyfov, znakov, ktoré majú podobný vzhľad, ale líšia sa významom a majú odlišné kódy unicode (napríklad znak „ɑ“ pripomína „ a", "ɡ" - "g", "ɩ" - "l"). Podobné znaky môžu byť použité v niektorých jazykoch v názvoch funkcií a premenných, aby zavádzali vývojárov. Napríklad môžu byť definované dve funkcie s nerozoznateľnými názvami, ktoré vykonávajú rôzne akcie. Bez podrobného rozboru nie je hneď jasné, ktorá z týchto dvoch funkcií sa volá na konkrétnom mieste.
V rámci bezpečnostného opatrenia sa odporúča, aby kompilátory, tlmočníci a nástroje zostavy, ktoré podporujú znaky Unicode, zobrazovali chybu alebo varovanie, ak sa v komentároch, reťazcových literáloch alebo identifikátoroch, ktoré menia smer výstupu, nachádzajú nespárované riadiace znaky (U+202A, U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E a U+200F). Takéto znaky by tiež mali byť výslovne zakázané v špecifikáciách programovacieho jazyka a mali by sa rešpektovať v editoroch kódu a rozhraniach úložísk.
Dodatok 1: Boli pripravené záplaty zraniteľnosti pre GCC, LLVM/Clang, Rust, Go, Python a binutils. Problém vyriešili aj GitHub, Bitbucket a Jira. Prebieha oprava pre GitLab. Na identifikáciu problematického kódu sa odporúča použiť príkaz: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069/]' /path zdroj
Dodatok 2: Russ Cox, jeden z vývojárov OS Plan 9 a programovacieho jazyka Go, kritizoval prílišnú pozornosť opísanej metóde útoku, ktorá je už dlho známa (Go, Rust, C++, Ruby) a neberie sa vážne. . Problém sa podľa Coxa týka najmä správneho zobrazovania informácií v editoroch kódu a webových rozhraniach, čo sa dá vyriešiť použitím správnych nástrojov a analyzátorov kódu pri kontrole. Namiesto upozorňovania na špekulatívne útoky by preto bolo vhodnejšie zamerať sa na zlepšenie procesov kontroly kódu a závislostí.
Ras Cox sa tiež domnieva, že kompilátory nie sú tým správnym miestom na riešenie problému, pretože zákazom nebezpečných symbolov na úrovni kompilátora zostáva obrovská vrstva nástrojov, v ktorých je používanie týchto symbolov stále prijateľné, ako sú zostavovacie systémy, assemblery, atď. správcov balíkov a rôzne konfiguračné analyzátory a údaje. Ako príklad je uvedený projekt Rust, ktorý zakázal spracovanie LTR/RTL kódu v kompilátore, no nepridal opravu do správcu balíkov Cargo, ktorý umožňuje podobný útok cez súbor Cargo.toml. Podobne sa zdrojmi útokov môžu stať súbory ako BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml a requirements.txt.
Zdroj: opennet.ru