Vědci z University of Cambridge zveřejnili techniku tichého vkládání škodlivého kódu do recenzovaného zdrojového kódu. Připravená metoda útoku (CVE-2021-42574) je prezentována pod názvem Trojan Source a je založena na vytváření textu, který vypadá odlišně pro kompilátora/interpreta a osobu prohlížející kód. Příklady metody jsou demonstrovány pro různé kompilátory a interprety dodávané pro C, C++ (gcc a clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go a Python.
Metoda je založena na použití speciálních znaků Unicode v komentářích kódu, které mění pořadí zobrazení obousměrného textu. Pomocí takových řídicích znaků lze některé části textu zobrazit zleva doprava, zatímco jiné - zprava doleva. V každodenní praxi lze takové řídicí znaky použít například pro vložení řádků kódu v hebrejštině nebo arabštině do souboru. Ale pokud zkombinujete řádky s různými směry textu v jednom řádku pomocí zadaných znaků, pasáže textu zobrazené zprava doleva mohou překrývat stávající běžný text zobrazený zleva doprava.
Pomocí této metody můžete do kódu přidat škodlivou konstrukci, ale poté text s touto konstrukcí zneviditelnit při prohlížení kódu přidáním následujícího komentáře nebo do doslovných znaků zobrazených zprava doleva, což povede k úplné na zákeřné vložení se překrývají různé postavy. Takový kód zůstane sémanticky správný, ale bude interpretován a zobrazován odlišně.
Při kontrole kódu bude vývojář konfrontován s vizuálním pořadím znaků a uvidí nepodezřelý komentář v moderním textovém editoru, webovém rozhraní nebo IDE, ale kompilátor a interpret použije logické pořadí znaků a zpracovat škodlivé vložení tak, jak je, aniž byste věnovali pozornost obousměrnému textu v komentářích. Problém se týká různých populárních editorů kódu (VS Code, Emacs, Atom), ale i rozhraní pro prohlížení kódu v repozitářích (GitHub, Gitlab, BitBucket a všechny produkty Atlassian).
Existuje několik způsobů, jak použít metodu k implementaci škodlivých akcí: přidání skrytého výrazu „návrat“, který vede k předčasnému dokončení funkce; komentování výrazů, které by normálně byly viditelné jako platné konstrukce (například pro zakázání důležitých kontrol); přiřazení jiných hodnot řetězce, které vedou k selhání ověření řetězce.
Útočník může například navrhnout změnu, která obsahuje řádek: if access_level != "user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}" {
která se zobrazí v rozhraní kontroly jako if access_level != “user” { // Zkontrolujte, zda je admin
Navíc byla navržena další varianta útoku (CVE-2021-42694), spojená s použitím homoglyfů, znaků, které jsou podobné vzhledem, ale liší se významem a mají různé kódy unicode (například znak „ɑ“ připomíná „ a", "ɡ" - "g", "ɩ" - "l"). Podobné znaky lze v některých jazycích použít v názvech funkcí a proměnných, aby uvedly vývojáře v omyl. Například mohou být definovány dvě funkce s nerozlišitelnými názvy, které provádějí různé akce. Bez podrobného rozboru není hned jasné, která z těchto dvou funkcí se na konkrétním místě volá.
Z bezpečnostních důvodů se doporučuje, aby kompilátory, interpreti a nástroje sestavení, které podporují znaky Unicode, zobrazily chybu nebo varování, pokud jsou v komentářích, řetězcových literálech nebo identifikátorech, které mění směr výstupu, nespárované řídicí 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). Takové znaky by také měly být výslovně zakázány ve specifikacích programovacího jazyka a měly by být respektovány v editorech kódu a rozhraních úložišť.
Dodatek 1: Byly připraveny opravy zranitelnosti pro GCC, LLVM/Clang, Rust, Go, Python a binutils. GitHub, Bitbucket a Jira také problém vyřešily. Probíhá oprava pro GitLab. Pro identifikaci problematické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 zdroj
Dodatek 2: Russ Cox, jeden z vývojářů OS Plan 9 a programovacího jazyka Go, kritizoval přílišnou pozornost věnovanou popsanému způsobu útoku, který je již dlouho znám (Go, Rust, C++, Ruby) a nebyl brán vážně. . Problém se podle Coxe týká především správného zobrazení informací v editorech kódu a webových rozhraních, což lze vyřešit použitím správných nástrojů a analyzátorů kódu při revizi. Místo upozorňování na spekulativní útoky by proto bylo vhodnější zaměřit se na zlepšování procesů kontroly kódu a závislostí.
Russ Cox se také domnívá, že kompilátory nejsou tím správným místem k vyřešení problému, protože zákazem nebezpečných symbolů na úrovni kompilátoru zůstává obrovská vrstva nástrojů, ve kterých je použití těchto symbolů přijatelné, jako jsou sestavovací systémy, assemblery, atd. správce balíčků a různé konfigurační analyzátory a data. Jako příklad je uveden projekt Rust, který zakázal zpracování LTR/RTL kódu v kompilátoru, ale nepřidal opravu do správce balíčků Cargo, který umožňuje podobný útok přes soubor Cargo.toml. Podobně se zdroje útoků mohou stát soubory jako BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml a requirements.txt.
Zdroj: opennet.ru