A Cambridge University researcher has published a technique for stealthily injecting malicious code into peer-reviewed source texts. The prepared attack method (CVE-2021-42574) is called Trojan Source and is based on generating text that appears differently to the compiler/interpreter and to the human viewing the code. Examples of the method's application have been demonstrated for various compilers and interpreters provided for languages such as C, C++ (gcc and clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go, and Python.
The method relies on using special Unicode characters in code comments that change the display order of bidirectional text. With such control characters, certain parts of the text can be rendered left-to-right while others right-to-left. In everyday practice, such control characters can be used, for example, to insert lines in Hebrew or Arabic into a code file. However, if lines with different text directions are combined in one line using these characters, segments of text displayed right-to-left can obscure existing normal text displayed left-to-right.
By using this method, a malicious construction can be added to the code, but then the text with this construction can be made invisible when viewing the code by adding in a subsequent comment or within a literal characters that are shown right-to-left, which will lead to the overlapping of the malicious insert with entirely different characters. Such code will remain semantically correct but will be interpreted and displayed differently.
During the code review process, the developer will encounter the visual order of symbol display and will see an unremarkable comment in a modern text editor, web interface, or IDE, but the compiler and interpreter will use the logical order of symbols and process the malicious insertion as it is, not paying attention to the bidirectional text in the comment. Various popular code editors (VS Code, Emacs, Atom) and interfaces for viewing code in repositories (GitHub, Gitlab, BitBucket, and all Atlassian products) are vulnerable to this issue.
Több módszert emelnek ki, amelyek segítségével a módszert rosszindulatú tevékenységek végrehajtására lehet felhasználni: rejtett „return” kifejezés hozzáadása, amely a funkció végrehajtásának korai befejezéséhez vezet; a normál módon látható kifejezések kommentbe zárása (például fontos ellenőrzések letiltása); más karakterlánc-értékek hozzárendelése, amelyek a karakterlánc-ellenőrzések meghibásodásához vezetnek.
Például a támadó javasolhat egy módosítást, amely magában foglalja a következő sort: if access_level != „user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}” {
amely a felhasználói felületen a következőképpen jelenik meg a felülvizsgálathoz: if access_level != „user” { // Check if admin
Továbbá egy másik támadási lehetőséget (CVE-2021-42694) is javasoltak, amely a homoglifákkal kapcsolatos, amelyek olyan karakterek, amelyek külsőleg hasonlítanak egymásra, de eltérő jelentéssel bírnak és különböző unicode-kódokkal rendelkeznek (például az „ɑ” karakter hasonlít az „a” karakterre, a „ɡ” az „g” karakterre, az „ɩ” pedig az „l” karakterre). Ilyen karakterek használhatók egyes nyelvekben funkciók és változók neveiben a fejlesztők megtévesztésére. Például két olyan funkció is meghatározható, amelyek nevei megkülönböztethetetlenek, de eltérő műveleteket hajtanak végre. Részletes elemzés nélkül nehéz megérteni, hogy ezek közül melyik funkció hívható meg egy adott helyen.
Védelmi intézkedésként ajánlott, hogy a Unicode-karaktereket támogató fordítókban, értelmezőkben és összeállító eszközökben hibajelzést vagy figyelmeztetést vezetnek be, ha páratlan vezérlőkarakterek találhatók a kommentárokban, karakterlánc-literalokban vagy azonosítókban, amelyek megváltoztatják a kimenet irányát (U+202A, U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E és U+200F). Az ilyen karaktereket a programozási nyelvek specifikációiban is egyértelműen meg kell tiltani, és figyelembe kell venni a kódszerkesztőkben és a repozitóriumokkal való munkához szükséges felületeken.
Kiegészítés 1: A sebezhetőség megszüntetésére vonatkozó javítások készültek a GCC, LLVM/Clang, Rust, Go, Python és binutils esetében. A problémát a GitHub, Bitbucket és Jira is orvosolta. A GitLab javítása folyamatban van. A problémás kód azonosításához javasolt parancs: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/source
Kiegészítés 2: Russ Cox, a Plan 9 operációs rendszer és a Go programozási nyelv egyik fejlesztője kritizálta a támadási módszerre való túlzott figyelmet, amely már régóta ismert (Go, Rust, C++, Ruby) és nem volt komolyan véve. Cox véleménye szerint a probléma elsősorban a kód szerkesztők és webes interfészek információjának helyes megjelenítésével kapcsolatos, amelyet megfelelő eszközök és kódelemzők alkalmazásával lehet megoldani a felülvizsgálat során. Így ahelyett, hogy a hipotetikus támadásokra irányítanánk a figyelmet, célszerűbb lenne a kód- és függőségi felülvizsgálati folyamatok javítására összpontosítani.
Russ Cox úgy véli, hogy a fordítók nem az a hely, ahol a problémát meg kellene oldani, mivel a veszélyes szimbólumok tilalmával a fordító szintjén még mindig hatalmas rész áll rendelkezésre, ahol ezen szimbólumok használata elfogadható, például a build rendszerekben, assembler-ekben, csomagkezelőkben és különböző konfigurációs és adatparszerekben. Példaként említi a Rust projektet, amely megtiltotta az LTR/RTL kód kezelését a fordítóban, de nem adott hozzá javítást a Cargo csomagkezelőhöz, ami hasonló támadásokat tesz lehetővé a Cargo.toml fájlon keresztül. Hasonlóképpen, a támadások forrásai lehetnek olyan fájlok, mint a BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml és requirements.txt.
Forrás: opennet.ru
