Výzkumníci z Cambridgeské univerzity zveřejnili techniku nenápadného vkládání škodlivého kódu do recenzovaných zdrojových textů. Připravená metodika útoku (CVE-2021-42574) je představena pod názvem Trojan Source a zakládá se na vytváření textu, který vypadá různě pro překladač/interpretr a člověka, který kód prohlíží. Příklady aplikace metody byly demonstrovány pro různé překladače a interpretery nabízené pro jazyky C, C++ (gcc a clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go a Python.
Metoda se zakládá na použití speciálních Unicode symbolů v komentářích kódu, které mění pořadí zobrazení víc směrového textu. Pomocí takových ovládacích znaků mohou být některé části textu zobrazeny zleva doprava, zatímco jiné zprava doleva. V běžné praxi mohou být takové ovládací znaky použity například pro vložení řetězců v hebrejštině nebo arabštině do kódu. Pokud však kombinujete řetězce s různými směry textu v jednom řetězci, pomocí uvedených znaků, mohou úryvky textu zobrazené zprava doleva překrýt již existující běžný text zobrazený zleva doprava.
Pomocí této metody lze do kódu přidat škodlivou konstrukci, ale poté udělat text s touto konstrukcí neviditelným při prohlížení kódu, přidáním do následujícího komentáře nebo uvnitř literálu znaků zobrazených zprava doleva, což povede k překryvu škodlivého vkladu úplně jinými znaky. Takový kód zůstane sémanticky správný, ale bude různě interpretován a zobrazen.
Během revize kódu se vývojář setká s vizuálním pořadím zobrazení znaků a uvidí v moderním textovém editoru, webovém rozhraní nebo IDE nenápadný komentář, ale překladač a interpret budou používat logické pořadí znaků a zpracují škodlivé vložení tak, jak je, aniž by brali v úvahu víc směrový text v komentáři. Problému podléhají různé populární editory kódu (VS Code, Emacs, Atom), stejně jako rozhraní pro prohlížení kódu v repozitářích (GitHub, Gitlab, BitBucket a všechny produkty Atlassian).
Existuje několik způsobů využití metody pro provádění škodlivých činností: přidání skrytého příkazu „return“, který způsobí předčasné ukončení provádění funkce; zakomponování výrazu do komentáře, což obvykle zamezuje jeho interpretaci jako platné konstrukce (například pro vypnutí důležitých kontrol); přiřazení jiných řetězcových hodnot, což vyvolává chyby v kontrolách řetězců.
Útočník může například navrhnout změnu, která zahrnuje řádku: if access_level != „user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}“ {
která se v rozhraní pro revizi zobrazí jako if access_level != „user“ { // Check if admin
Dále byl navržen další variant útoku (CVE-2021-42694), související s využíváním homoglifů, symbolů, které vypadají podobně, ale mají jiný význam a odlišné unicode kódy (například symbol „ɑ“ vypadá jako „a“, „ɡ“ jako „g“, „ɩ“ jako „l“). Tyto symboly lze v některých jazycích použít v názvech funkcí a proměnných, aby se vývojáři nechali zmást. Například mohou být definovány dvě funkce se neodlišitelnými názvy, které vykonávají různé akce. Bez podrobného prozkoumání není hned jasné, která z těchto dvou funkcí je v konkrétním místě volána.
Jako bezpečnostní opatření se doporučuje implementovat v kompilátorech, interpretrátorech a nástrojích na sestavování, které podporují Unicode symboly, upozornění nebo varování při přítomnosti neparních řídicích znaků měnících směr výstupu (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). Tyto symboly by měly být také výslovně zakázány ve specifikacích programovacích jazyků a měly by být brány v úvahu v kódových editorech a rozhraních pro práci s repozitáři.
Doplněk 1: Opravy k odstranění zranitelnosti byly připraveny pro GCC, LLVM/Clang, Rust, Go, Python a binutils. Problém také vyřešily GitHub, Bitbucket a Jira. Nyní se připravuje oprava pro GitLab. Pro identifikaci problémového kódu se doporučuje použít příkaz: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/source
Doplňující informace 2: Russ Cox, jeden z vývojářů operačního systému Plan 9 a programovacího jazyka Go, kritizoval nadměrnou pozornost věnovanou popsané metodě útoku, která je již dlouho známá (Go, Rust, C++, Ruby) a nebyla brána vážně. Podle Coxa se problém většinou týká správnosti zobrazení informací v kódových editorech a webových rozhraních a řeší se použitím správných nástrojů a analyzátorů kódu při posuzování. Proto by bylo správnější místo upoutávání pozornosti na teoretické útoky zaměřit se na zlepšování recenzních procesů kódu a závislostí.
Russ Cox také tvrdí, že kompilátory nejsou tím místem, kde by se mělo problém řešit, protože zakázáním nebezpečných symbolů na úrovni kompilátoru zůstává obrovské množství nástrojů, ve kterých je použití těchto symbolů stále povoleno, jako jsou systémy sestavení, assembleru, správci balíčků a různé analyzátory konfigurace a dat. Jako příklad je uveden projekt Rust, který zakázal zpracování kódu LTR/RTL v kompilátoru, ale nepřidal opravu do správce balíčků Cargo, což umožňuje provést podobný útok prostřednictvím souboru Cargo.toml. Podobně mohou být zdrojem útoků takové soubory jako BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml a requirements.txt.
Zdroj: opennet.ru
