A Cambridge-i Egyetem kutatói közzétettek egy technikát, amellyel rosszindulatú kódokat lehet csendesen beilleszteni a lektorált forráskódba. Az előkészített támadási módszer (CVE-2021-42574) Trojan Source néven jelenik meg, és a fordító/tolmács és a kódot megtekintő személy számára eltérő szövegalkotáson alapul. A módszerre példákat mutatunk be a C, C++ (gcc és clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go és Python nyelvekhez szállított fordítókhoz és értelmezőkhöz.
A módszer speciális Unicode karakterek használatán alapul a kód megjegyzésekben, amelyek megváltoztatják a kétirányú szöveg megjelenítési sorrendjét. Az ilyen vezérlőkarakterek segítségével a szöveg egyes részei balról jobbra, mások pedig jobbról balra jeleníthetők meg. A mindennapi gyakorlatban ilyen vezérlőkarakterek használhatók például héber vagy arab nyelvű kódsorok beszúrására egy fájlba. De ha egy sorban kombinálja a különböző szövegirányokkal rendelkező sorokat, akkor a megadott karakterek használatával a jobbról balra megjelenített szövegrészek átfedhetik a balról jobbra megjelenített meglévő normál szöveget.
Ezzel a módszerrel hozzáadhat egy rosszindulatú konstrukciót a kódhoz, de az ezzel a konstrukcióval rendelkező szöveget láthatatlanná teheti a kód megtekintésekor, ha a következő megjegyzésbe vagy a jobbról balra látható literális karakterek belsejébe írja be, ami teljesen a különböző karakterek kerülnek a rosszindulatú beillesztésre. Az ilyen kód szemantikailag helyes marad, de másképpen értelmeződik és jelenik meg.
A kód áttekintése során a fejlesztő szembesül a karakterek vizuális sorrendjével, és egy nem gyanús megjegyzést lát egy modern szövegszerkesztőben, webes felületen vagy IDE-ben, de a fordító és az értelmező a karakterek logikai sorrendjét használja, és dolgozza fel a rosszindulatú beillesztést úgy, ahogy van, anélkül, hogy figyelne a megjegyzésekben található kétirányú szövegre. A probléma különböző népszerű kódszerkesztőket (VS Code, Emacs, Atom), valamint a lerakatokban található kódmegtekintési felületeket (GitHub, Gitlab, BitBucket és minden Atlassian termék) érinti.
Számos módja van a módszernek a rosszindulatú műveletek végrehajtására: rejtett „visszatérés” kifejezés hozzáadása, amely a funkció idő előtti befejezéséhez vezet; olyan kifejezések megjegyzése, amelyek normál esetben érvényes konstrukcióként láthatók (például a fontos ellenőrzések letiltásához); más karakterlánc-értékek hozzárendelése, amelyek a karakterlánc-ellenőrzési hibákhoz vezetnek.
Például egy támadó javasolhat egy változtatást, amely tartalmazza a következő sort: if access_level != "user{U+202E} {U+2066}// Ellenőrizze, hogy admin{U+2069} {U+2066}" {
amely úgy jelenik meg a felülvizsgálati felületen, mintha hozzáférési_szint != “felhasználó” { // Ellenőrizze, hogy admin-e
Ezenkívül egy másik támadási változatot javasoltak (CVE-2021-42694), amely homoglifák használatához kapcsolódik, olyan karakterek használatához, amelyek megjelenésükben hasonlóak, de jelentésükben eltérőek és eltérő unicode kódokkal rendelkeznek (például az „ɑ” karakter hasonlít a „ a”, „ɡ” - „g”, „ɩ” - „l”). Néhány nyelven hasonló karakterek használhatók a függvények és változók nevében a fejlesztők megtévesztésére. Például két, egymástól megkülönböztethetetlen nevű függvény definiálható, amelyek különböző műveleteket hajtanak végre. Részletes elemzés nélkül nem egyértelmű, hogy a két funkció közül melyiket hívják meg egy adott helyen.
Biztonsági intézkedésként javasoljuk, hogy a Unicode karaktereket támogató fordítók, értelmezők és összeállító eszközök hibát vagy figyelmeztetést jelenítsenek meg, ha párosítatlan vezérlőkarakterek vannak a megjegyzésekben, karakterlánc-literálokban vagy olyan 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 kifejezetten meg kell tiltani a programozási nyelv specifikációiban, és tiszteletben kell tartani a kódszerkesztőkben és a tárolófelületeken.
1. kiegészítés: Sebezhetőségi javításokat készítettek a GCC, LLVM/Clang, Rust, Go, Python és a binutils számára. A GitHub, a Bitbucket és a Jira is javította a problémát. A GitLab javítása folyamatban van. A problémás kód azonosításához a következő parancsot javasoljuk: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/ forrás
2. kiegészítés: Russ Cox, a Plan 9 OS és a Go programozási nyelv egyik fejlesztője bírálta a leírt támadási módszer túlzott odafigyelését, amely régóta ismert (Go, Rust, C++, Ruby) és nem vették komolyan. . Cox szerint a probléma elsősorban a kódszerkesztőkben és a webes felületeken való helyes információmegjelenítéssel kapcsolatos, amit a megfelelő eszközök és kódelemzők használatával lehet megoldani a felülvizsgálat során. Ezért ahelyett, hogy a spekulatív támadásokra hívnák fel a figyelmet, helyénvalóbb lenne a kód- és függőségi felülvizsgálati folyamatok javítására összpontosítani.
Ras Cox úgy véli továbbá, hogy a fordítók nem a megfelelő hely a probléma megoldására, hiszen a veszélyes szimbólumok fordítói szintű betiltásával hatalmas eszközréteg marad, amelyben továbbra is elfogadható ezeknek a szimbólumoknak a használata, mint például a build rendszerek, assemblerek, csomagkezelők és különféle konfigurációs elemzők és adatok. Példaként a Rust projektet hozzuk fel, amely megtiltotta az LTR/RTL kód feldolgozását a fordítóban, de nem adott hozzá egy javítást a Cargo csomagkezelőhöz, ami hasonló támadást tesz lehetővé a Cargo.toml fájlon keresztül. Hasonlóképpen, az olyan fájlok, mint a BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml és követelmények.txt, támadások forrásává válhatnak.
Forrás: opennet.ru