Trojan Source-attack för att införliva ändringar i koden som är osynliga för utvecklaren.

Forskare vid Cambridge University har publicerat en teknik för osynlig införande av skadlig kod i granskade källkoder. Den förberedda attackmetoden (CVE-2021-42574) presenteras under namnet Trojan Source och baseras på att texten formar sig så att den ser annorlunda ut för kompilatorn/interpreten och för en människa som granskar koden. Exempel på tillämpning av metoden har demonstrerats för olika kompilatorer och interpreters som används för språken C, C++ (gcc och clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go och Python.

Metoden bygger på användning av speciella Unicode-tecken i kommentarer i koden som ändrar visningsordningen av tvåvägs text. Genom sådana kontrolltecken kan vissa delar av texten visas vänster-till-höger, medan andra kan visas höger-till-vänster. I praktiken kan sådana kontrolltecken till exempel användas för att införa rader med hebreiska eller arabiska tecken i en kodfil. Men om man kombinerar strängar med olika textinriktningar i en och samma rad, kan delar av texten som visas höger-till-vänster, med hjälp av nämnda tecken, överlappa vanlig text som visas vänster-till-höger.

Genom att använda denna metod kan en skadlig konstruktion läggas till i koden, men sedan göras osynlig vid granskning av koden genom att lägga till tecken som visas höger-till-vänster i efterföljande kommentar eller inom en litterär sträng, vilket resulterar i att dessa tecken överlappar den skadliga infogningen med helt andra tecken. Sådan kod kommer att förbli semantiskt korrekt, men kommer att tolkas och visas olika.

Vid kodgranskning kommer utvecklaren att stöta på den visuella ordningen för tecken och se en oklanderlig kommentar i en modern textredigerare, webbadministratör eller IDE, medan kompilatorn och interpreten kommer att använda den logiska teckenordningen och bearbeta den skadliga infogningen som den är, utan att uppmärksamma den tvåvägs texten i kommentaren. Problemet gäller olika populära kodredigerare (VS Code, Emacs, Atom) samt gränssnitt för att visa kod i repositorier (GitHub, Gitlab, BitBucket och alla produkter från Atlassian).

Det finns flera sätt att använda metoden för att utföra skadliga handlingar: att lägga till ett dolt uttryck "return", vilket leder till att funktionen avslutas i förtid; att dölja uttryck i kommentarer, som normalt visas som giltiga konstruktioner (till exempel för att inaktivera viktiga kontroller); att tilldela andra strängvärden som orsakar att strängkontroller misslyckas.

Till exempel kan en angripare föreslå en ändring som inkluderar raden: if access_level != «user{U+202E} {U+2066}// Kontrollera om admin{U+2069} {U+2066}» {

som kommer att visas i gränssnittet för granskning som if access_level != «user» { // Kontrollera om admin

Dessutom har en annan attackvariant föreslagits (CVE-2021-42694), relaterad till användning av homoglyfer, tecken som liknar varandra i utseende men skiljer sig åt i betydelse och har olika unicode-koder (till exempel symbolen «ɑ» påminner om «a», «ɡ» — «g», «ɩ» — «l»). Sådana tecken kan användas i vissa språk i funktions- och variabelnamn för att förvirra utvecklare. Till exempel kan två funktioner definieras med oidentifierbara namn som utför olika åtgärder. Utan noggrann granskning är det svårt att avgöra vilken av dessa två funktioner som anropas på en viss plats.

Som en skyddsåtgärd rekommenderas att implementera felmeddelanden eller varningar i kompilatorer, tolkare och byggverktyg som stöder Unicode-tecken, när udda kontrolltecken som ändrar utmatningsriktning (U+202A, U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E och U+200F) finns i kommentarer, stränglitteraler eller identifierare. Sådana tecken bör också vara uttryckligen förbjudna i programmeringsspråkets specifikationer och beaktas i kodredigerare och gränssnitt för arbete med databaser.

Tillägg 1: Korrigeringar för att åtgärda sårbarheten har förberetts för GCC, LLVM/Clang, Rust, Go, Python och binutils. Problemet har också åtgärdats av GitHub, Bitbucket och Jira. Ett fix för GitLab är under beredning. För att identifiera problematisk kod föreslås kommandot: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/source

Tillägg 2: Russ Cox, en av utvecklarna av operativsystemet Plan 9 och programmeringsspråket Go, har kritiserat den överdrivna uppmärksamheten på den beskrivna attackmetoden, som länge har varit känd (Go, Rust, C++, Ruby) och som inte har tagits på allvar. Enligt Cox rör sig problemet främst kring korrekt visning av information i kodredigerare och webgränssnitt, vilket kan lösas genom att använda rätt verktyg och kodanalysatorer vid granskning. Därför skulle det vara mer korrekt att fokusera på att förbättra processerna för kodgranskning och beroenden istället för att rikta uppmärksamhet mot hypotetiska attacker.

Russ Cox anser också att kompilatorer inte är den rätta platsen att åtgärda problemet, eftersom det finns ett enormt antal verktyg där användning av dessa symboler förblir tillåten, såsom byggsystem, assemblatorer, paketchefer och olika konfigurations- och dataparserare. Ett exempel är projektet Rust, som förbjöd bearbetning av LTR/RTL-kod i kompilatorn, men inte lade till en lösning i paketchefen Cargo, vilket gör att en liknande attack kan utföras genom filen Cargo.toml. På samma sätt kan filerna BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml och requirements.txt fungera som angreppskällor.

Källa: opennet.ru