Forskere fra University of Cambridge har offentliggjort en teknik til lydløst at indsætte ondsindet kode i peer-reviewed kildekode. Den forberedte angrebsmetode (CVE-2021-42574) præsenteres under navnet Trojan Source og er baseret på dannelsen af tekst, der ser anderledes ud for compileren/tolken og den person, der ser koden. Eksempler på metoden er demonstreret for forskellige compilere og fortolkere leveret til C, C++ (gcc og clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go og Python.
Metoden er baseret på brug af specielle Unicode-tegn i kodekommentarer, der ændrer visningsrækkefølgen af tovejstekst. Ved hjælp af sådanne kontroltegn kan nogle dele af teksten vises fra venstre mod højre, mens andre - fra højre mod venstre. I daglig praksis kan sådanne kontroltegn fx bruges til at indsætte kodelinjer på hebraisk eller arabisk i en fil. Men hvis du kombinerer linjer med forskellige tekstretninger på én linje, ved hjælp af de angivne tegn, kan tekstpassager, der vises fra højre mod venstre, overlappe eksisterende almindelig tekst, der vises fra venstre mod højre.
Ved at bruge denne metode kan du tilføje en ondsindet konstruktion til koden, men derefter gøre teksten med denne konstruktion usynlig, når du ser koden, ved at tilføje i følgende kommentar eller inde i de bogstavelige tegn vist fra højre mod venstre, hvilket vil føre til fuldstændig forskellige tegn bliver lagt oven på den ondsindede indsættelse. En sådan kode vil forblive semantisk korrekt, men vil blive fortolket og vist anderledes.
Mens en udvikler gennemgår kode, vil en udvikler blive konfronteret med den visuelle rækkefølge af tegnene og vil se en ikke-mistænkelig kommentar i en moderne teksteditor, webgrænseflade eller IDE, men compileren og fortolkeren vil bruge den logiske rækkefølge af tegnene og vil behandle den ondsindede indsættelse som den er, uden at være opmærksom på den tovejstekst i kommentarerne. Problemet påvirker forskellige populære kodeeditorer (VS Code, Emacs, Atom) samt grænseflader til visning af kode i repositories (GitHub, Gitlab, BitBucket og alle Atlassian-produkter).
Der er flere måder at bruge metoden til at implementere ondsindede handlinger: tilføjelse af et skjult "retur"-udtryk, som fører til færdiggørelsen af funktionen før tid; kommentere udtryk, der normalt ville være synlige som gyldige konstruktioner (for eksempel for at deaktivere vigtige kontroller); tildeling af andre strengværdier, der fører til strengvalideringsfejl.
For eksempel kan en hacker foreslå en ændring, der inkluderer linjen: if access_level != "user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}" {
som vil blive vist i gennemgangsgrænsefladen som om access_level != “user” {// Tjek om admin
Derudover er en anden angrebsvariant blevet foreslået (CVE-2021-42694), forbundet med brugen af homoglyffer, tegn, der ligner hinanden i udseende, men afviger i betydning og har forskellige unicode-koder (for eksempel ligner tegnet "ɑ" " a", "ɡ" - "g", "ɩ" - "l"). Lignende tegn kan bruges på nogle sprog i navnene på funktioner og variabler for at vildlede udviklere. For eksempel kan to funktioner med navne, der ikke kan skelnes, defineres, som udfører forskellige handlinger. Uden en detaljeret analyse er det ikke umiddelbart klart, hvilken af disse to funktioner, der kaldes et bestemt sted.
Som en sikkerhedsforanstaltning anbefales det, at compilere, fortolkere og assemblerværktøjer, der understøtter Unicode-tegn, viser en fejl eller advarsel, hvis der er uparrede kontroltegn i kommentarer, strenge bogstaver eller identifikatorer, der ændrer outputretningen (U+202A, U+202B, U +202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E og U+200F). Sådanne tegn bør også udtrykkeligt forbydes i programmeringssprogsspecifikationer og bør respekteres i kodeeditorer og lagergrænseflader.
Tillæg 1: Der er udarbejdet sårbarhedspatches til GCC, LLVM/Clang, Rust, Go, Python og binutils. GitHub, Bitbucket og Jira løste også problemet. En rettelse til GitLab er i gang. For at identificere problematisk kode, foreslås det at bruge kommandoen: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202C\u2066D\u2067E\u2068\u2069\uXNUMX\uXNUMX/' kilde
Tillæg 2: Russ Cox, en af udviklerne af Plan 9 OS og Go-programmeringssproget, kritiserede den overdrevne opmærksomhed på den beskrevne angrebsmetode, som længe har været kendt (Go, Rust, C++, Ruby) og ikke blev taget alvorligt . Ifølge Cox handler problemet hovedsageligt om korrekt visning af information i kodeeditorer og webgrænseflader, som kan løses ved at bruge de korrekte værktøjer og kodeanalysatorer under gennemgangen. I stedet for at henlede opmærksomheden på spekulative angreb, ville det derfor være mere hensigtsmæssigt at fokusere på at forbedre processerne for gennemgang af kode og afhængighed.
Ras Cox mener også, at compilere ikke er det rigtige sted at løse problemet, da ved at forbyde farlige symboler på compilerniveau, er der stadig et stort lag af værktøjer, hvor brugen af disse symboler forbliver acceptabel, såsom byggesystemer, assemblere, pakkeadministratorer og forskellige konfigurationsparsere og data. Som et eksempel er Rust-projektet givet, som forbød behandling af LTR/RTL-kode i compileren, men ikke tilføjede en rettelse til Cargo-pakkehåndteringen, som tillader et lignende angreb gennem Cargo.toml-filen. På samme måde kan filer som BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml og requirements.txt blive kilder til angreb.
Kilde: opennet.ru