Forskere fra University of Cambridge har offentliggjort en teknik til uopdagelig indsættelse af ondsindet kode i fagfællebedømt kildekode. Den forberedte angrebsmetode (CVE-2021-42574) præsenteres under navnet Trojan Source og er baseret på dannelsen af tekst, der ser forskelligt ud for compileren/fortolkeren og den person, der ser koden. Eksempler på metodeanvendelser demonstreres for forskellige compilere og fortolkere, der leveres til sprogene C, C++ (gcc og clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go og Python.
Metoden er baseret på brugen af særlige Unicode-symboler i kodekommentarer, der ændrer den rækkefølge, hvori tovejstekst vises. Ved hjælp af sådanne kontroltegn kan nogle dele af teksten vises fra venstre mod højre, mens andre kan vises fra højre mod venstre. I daglig praksis kan sådanne kontroltegn f.eks. bruges til at indsætte hebraiske eller arabiske strenge i en kodefil. Men hvis du kombinerer linjer med forskellige tekstretninger på den samme linje ved hjælp af disse tegn, kan højre-mod-venstre-teksten overlappe den eksisterende normale venstre-mod-højre-tekst.
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 symboler vist fra højre mod venstre i den næste kommentar eller inde i den kritiske sætning, hvilket vil resultere i, at helt andre symboler bliver lagt oven på den ondsindede indsættelse. Sådan kode vil forblive semantisk korrekt, men vil blive fortolket og vist forskelligt.
Under kodegennemgang vil udvikleren blive konfronteret med den visuelle rækkefølge af tegnene og vil se en uskadelig kommentar i en moderne teksteditor, webgrænseflade eller IDE, men compileren og fortolkeren vil bruge den logiske rækkefølge af tegn og vil behandle den ondsindede indsættelse, som den er, og ignorere den tovejstekst i kommentaren. 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 udføre ondsindede handlinger: tilføjelse af et skjult "return"-udtryk, som får funktionen til at afsluttes for tidligt; at omslutte udtryk i en kommentar, der normalt er synlige som aktive konstruktioner (for eksempel for at deaktivere vigtige kontroller); tildeling af andre strengværdier, der forårsager strengvalideringsfejl.
For eksempel kan en angriber 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 != "bruger" { // Marker hvis admin
Derudover er der blevet foreslået en anden angrebsvariant (CVE-2021-42694), der er relateret til brugen af homoglyffer, symboler der ligner hinanden i udseende, men har forskellige betydninger og forskellige Unicode-koder (for eksempel ligner symbolet "ɑ" "a", "ɡ" ligner "g", "ɩ" ligner "l"). Sådanne tegn kan i nogle sprog bruges i funktions- og variabelnavne for at vildlede udviklere. For eksempel kan der defineres to funktioner med identiske navne, der udfører forskellige handlinger. Uden en detaljeret analyse er det ikke umiddelbart klart, hvilken af disse to funktioner der kaldes på et bestemt sted.
Som en sikkerhedsforanstaltning anbefales det, at compilere, fortolkere og byggeværktøjer, der understøtter Unicode-tegn, genererer en fejl eller advarsel, når kommentarer, strengliteraler eller identifikatorer indeholder uparrede kontroltegn, 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å eksplicit forbydes i specifikationer for programmeringssprog og bør tages i betragtning i kodeeditorer og repository-grænseflader.
Tillæg 1: Rettelser til at afhjælpe sårbarheden er blevet udarbejdet til GCC, LLVM/Clang, Rust, Go, Python og binutils. Problemet er også blevet løst af GitHub, Bitbucket og Jira. En rettelse til GitLab er under forberedelse. For at identificere den problematiske kode foreslås det at bruge kommandoen: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /sti/til/kilde
Tillæg 2: Russ Cox, en af udviklerne af Plan 9 OS og programmeringssproget Go, kritiserede den overdrevne opmærksomhed på den beskrevne angrebsmetode, som har været kendt i lang tid (Go, Rust, C++, Ruby) og ikke blev taget alvorligt. Ifølge Cox drejer problemet sig primært om den korrekte visning af information i kodeeditorer og webgrænseflader, og det kan løses ved at bruge de korrekte værktøjer og kodeanalysatorer under gennemgangen. Så i stedet for at fokusere på spekulative angreb, ville det være mere passende at fokusere på at forbedre kode- og afhængighedsgennemgangsprocesser.
Russ Cox mener også, at compilere ikke er stedet til at løse problemet, da forbud mod farlige symboler på compilerniveau efterlader et enormt lag af værktøjer, hvor brugen af disse symboler fortsat er tilladt, såsom byggesystemer, assemblere, pakkehåndteringsværktøjer og forskellige konfigurations- og dataparsere. Som et eksempel gives Rust-projektet, 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 at blive udført via Cargo.toml-filen. Tilsvarende kan filer som BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml og requirements.txt være kilder til angreb.
Kilde: opennet.ru
