Forskere fra University of Cambridge har publisert en teknikk for å stille inn ondsinnet kode i fagfellevurdert kildekode. Den forberedte angrepsmetoden (CVE-2021-42574) presenteres under navnet Trojan Source og er basert på dannelsen av tekst som ser annerledes ut for kompilatoren/tolken og personen som ser på koden. Eksempler på metoden er demonstrert for ulike kompilatorer og tolker levert for C, C++ (gcc og clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go og Python.
Metoden er basert på bruk av spesielle Unicode-tegn i kodekommentarer som endrer visningsrekkefølgen til toveis tekst. Ved hjelp av slike kontrolltegn kan noen deler av teksten vises fra venstre til høyre, mens andre - fra høyre til venstre. I daglig praksis kan slike kontrolltegn for eksempel brukes til å sette inn kodelinjer på hebraisk eller arabisk i en fil. Men hvis du kombinerer linjer med forskjellige tekstretninger på én linje, ved å bruke de angitte tegnene, kan tekstpassasjer som vises fra høyre til venstre overlappe eksisterende vanlig tekst vist fra venstre mot høyre.
Ved å bruke denne metoden kan du legge til en ondsinnet konstruksjon i koden, men deretter gjøre teksten med denne konstruksjonen usynlig når du ser på koden, ved å legge til i følgende kommentar eller inne i de bokstavelige tegnene vist fra høyre til venstre, noe som vil føre til fullstendig forskjellige tegn legges over den ondsinnede innsettingen. Slik kode vil forbli semantisk korrekt, men vil bli tolket og vist annerledes.
Mens en utvikler gjennomgår koden, vil en utvikler bli konfrontert med den visuelle rekkefølgen til tegnene og vil se en ikke-mistenkelig kommentar i et moderne tekstredigeringsprogram, nettgrensesnitt eller IDE, men kompilatoren og tolken vil bruke den logiske rekkefølgen til tegnene og vil behandle den ondsinnede innsettingen som den er, uten å ta hensyn til toveisteksten i kommentarene. Problemet påvirker ulike populære koderedigerere (VS Code, Emacs, Atom), samt grensesnitt for visning av kode i repositories (GitHub, Gitlab, BitBucket og alle Atlassian-produkter).
Det er flere måter å bruke metoden til å implementere ondsinnede handlinger: legge til et skjult "retur"-uttrykk, som fører til fullføring av funksjonen på forhånd; kommentere uttrykk som normalt vil være synlige som gyldige konstruksjoner (for eksempel for å deaktivere viktige kontroller); tilordne andre strengverdier som fører til strengvalideringsfeil.
En angriper kan for eksempel foreslå en endring som inkluderer linjen: if access_level != "user{U+202E} {U+2066}// Sjekk om admin{U+2069} {U+2066}" {
som vil bli vist i gjennomgangsgrensesnittet som om access_level != “user” {// Sjekk om admin
I tillegg har en annen angrepsvariant blitt foreslått (CVE-2021-42694), assosiert med bruken av homoglyfer, tegn som er like i utseende, men forskjellige i betydning og har forskjellige unicode-koder (for eksempel ligner tegnet "ɑ" " a", "ɡ" - "g", "ɩ" - "l"). Lignende tegn kan brukes på noen språk i navnene på funksjoner og variabler for å villede utviklere. For eksempel kan to funksjoner med navn som ikke kan skilles være definert som utfører forskjellige handlinger. Uten en detaljert analyse er det ikke umiddelbart klart hvilken av disse to funksjonene som kalles på et bestemt sted.
Som et sikkerhetstiltak anbefales det at kompilatorer, tolkere og monteringsverktøy som støtter Unicode-tegn viser en feil eller advarsel hvis det er uparrede kontrolltegn i kommentarer, strengbokstaver eller identifikatorer som endrer utdataretningen (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). Slike tegn bør også være eksplisitt forbudt i programmeringsspråkspesifikasjoner og bør respekteres i koderedigerere og arkivgrensesnitt.
Tillegg 1: Sårbarhetsoppdateringer er utarbeidet for GCC, LLVM/Clang, Rust, Go, Python og binutils. GitHub, Bitbucket og Jira løste også problemet. En rettelse for GitLab pågår. For å identifisere problematisk kode, anbefales det å bruke kommandoen: grep -r $'[\u061C\u200E\u200E\u202A\u202B\u202C\u202D\u202C\u2066D\u2067E\u2068\u2069\uXNUMX\uXNUMX/' kilde
Tillegg 2: Russ Cox, en av utviklerne av Plan 9 OS og Go-programmeringsspråket, kritiserte den overdrevne oppmerksomheten til den beskrevne angrepsmetoden, som lenge har vært kjent (Go, Rust, C++, Ruby) og ikke ble tatt på alvor . Ifølge Cox dreier problemet seg i hovedsak om korrekt visning av informasjon i koderedigerere og nettgrensesnitt, som kan løses ved å bruke riktige verktøy og kodeanalysatorer under gjennomgang. Derfor, i stedet for å trekke oppmerksomhet til spekulative angrep, ville det være mer hensiktsmessig å fokusere på å forbedre prosesser for gjennomgang av kode og avhengighet.
Ras Cox mener også at kompilatorer ikke er det rette stedet å fikse problemet, siden ved å forby farlige symboler på kompilatornivå, gjenstår det et stort lag med verktøy der bruken av disse symbolene fortsatt er akseptabelt, for eksempel byggesystemer, montører, pakkebehandlere og ulike konfigurasjonsparsere og data. Som et eksempel er Rust-prosjektet gitt, som forbød behandling av LTR/RTL-kode i kompilatoren, men ikke la til en rettelse til Cargo-pakkebehandlingen, som tillater et lignende angrep gjennom Cargo.toml-filen. På samme måte kan filer som BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml og requirements.txt bli kilder til angrep.
Kilde: opennet.ru