Forskare från University of Cambridge har publicerat en teknik för att tyst infoga skadlig kod i peer-reviewed källkod. Den förberedda attackmetoden (CVE-2021-42574) presenteras under namnet Trojan Source och baseras på bildandet av text som ser annorlunda ut för kompilatorn/tolken och den som tittar på koden. Exempel på metoden visas för olika kompilatorer och tolkar som tillhandahålls för C, C++ (gcc och clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go och Python.
Metoden är baserad på användningen av speciella Unicode-tecken i kodkommentarer som ändrar visningsordningen för dubbelriktad text. Med hjälp av sådana kontrolltecken kan vissa delar av texten visas från vänster till höger, medan andra - från höger till vänster. I den dagliga praktiken kan sådana kontrolltecken användas för att till exempel infoga kodrader på hebreiska eller arabiska i en fil. Men om du kombinerar rader med olika textriktningar på en rad, med de angivna tecknen, kan textavsnitt som visas från höger till vänster överlappa befintlig vanlig text som visas från vänster till höger.
Med den här metoden kan du lägga till en skadlig konstruktion till koden, men sedan göra texten med denna konstruktion osynlig när du tittar på koden, genom att lägga till i följande kommentar eller inuti de bokstavliga tecknen som visas från höger till vänster, vilket kommer att leda till helt olika tecken läggs ovanpå den skadliga infogningen. Sådan kod kommer att förbli semantiskt korrekt, men kommer att tolkas och visas annorlunda.
När en utvecklare granskar koden kommer en utvecklare att konfronteras med karaktärernas visuella ordning och kommer att se en icke misstänkt kommentar i en modern textredigerare, webbgränssnitt eller IDE, men kompilatorn och tolken kommer att använda den logiska ordningen för tecknen och bearbeta den skadliga infogningen som den är, utan att uppmärksamma den dubbelriktade texten i kommentarerna. Problemet påverkar olika populära kodredigerare (VS Code, Emacs, Atom), såväl som gränssnitt för visning av kod i repositories (GitHub, Gitlab, BitBucket och alla Atlassian-produkter).
Det finns flera sätt att använda metoden för att implementera skadliga åtgärder: lägga till ett dolt "retur"-uttryck, vilket leder till att funktionen slutförs i förväg; kommentera uttryck som normalt skulle vara synliga som giltiga konstruktioner (till exempel för att inaktivera viktiga kontroller); tilldela andra strängvärden som leder till strängvalideringsfel.
En angripare kan till exempel 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 granskningsgränssnittet som om access_level != “user” {// Kontrollera om admin
Dessutom har en annan attackvariant föreslagits (CVE-2021-42694), förknippad med användningen av homoglyfer, tecken som liknar utseende, men skiljer sig i betydelse och har olika unicode-koder (till exempel liknar tecknet "ɑ" " a", "ɡ" - "g", "ɩ" - "l"). Liknande tecken kan användas på vissa språk i namnen på funktioner och variabler för att vilseleda utvecklare. Till exempel kan två funktioner med oskiljbara namn definieras som utför olika åtgärder. Utan en detaljerad analys är det inte omedelbart klart vilken av dessa två funktioner som kallas på en specifik plats.
Som en säkerhetsåtgärd rekommenderas det att kompilatorer, tolkar och monteringsverktyg som stöder Unicode-tecken visar ett fel eller en varning om det finns oparade kontrolltecken i kommentarer, bokstavssträngar eller identifierare som ändrar utmatningsriktningen (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). Sådana tecken bör också uttryckligen förbjudas i programmeringsspråksspecifikationer och bör respekteras i kodredigerare och arkivgränssnitt.
Tillägg 1: Sårbarhetskorrigeringar har förberetts för GCC, LLVM/Clang, Rust, Go, Python och binutils. GitHub, Bitbucket och Jira fixade också problemet. En fix för GitLab pågår. För att identifiera problematisk kod, föreslås det att du använder kommandot: grep -r $'[\u061C\u200E\u200E\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069/' källa
Tillägg 2: Russ Cox, en av utvecklarna av Plan 9 OS och programmeringsspråket Go, kritiserade den överdrivna uppmärksamheten på den beskrivna attackmetoden, som länge varit känd (Go, Rust, C++, Ruby) och inte togs på allvar . Enligt Cox handlar problemet främst om korrekt visning av information i kodredigerare och webbgränssnitt, vilket kan lösas genom att använda rätt verktyg och kodanalysatorer vid granskning. Därför, istället för att uppmärksamma spekulativa attacker, vore det mer lämpligt att fokusera på att förbättra processer för kod och beroendegranskning.
Ras Cox anser också att kompilatorer inte är rätt ställe att åtgärda problemet, eftersom genom att förbjuda farliga symboler på kompilatornivå finns det ett enormt lager av verktyg där användningen av dessa symboler förblir acceptabel, såsom byggsystem, assemblers, pakethanterare och olika konfigurationstolkare och data. Som ett exempel ges Rust-projektet, som förbjöd bearbetning av LTR/RTL-kod i kompilatorn, men inte lade till en fix till Cargo-pakethanteraren, som tillåter en liknande attack genom filen Cargo.toml. På liknande sätt kan filer som BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml och requirements.txt bli källor till attacker.
Källa: opennet.ru