Onderzoekers van de Universiteit van Cambridge hebben een techniek gepubliceerd waarmee kwaadaardige code in peer-reviewed broncode kan worden ingevoegd. De voorbereide aanvalsmethode (CVE-2021-42574) wordt gepresenteerd onder de naam Trojan Source en is gebaseerd op de vorming van tekst die er anders uitziet voor de compiler/interpreter en de persoon die de code bekijkt. Er worden voorbeelden van de methode gedemonstreerd voor verschillende compilers en tolken die worden geleverd voor C, C++ (gcc en clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go en Python.
De methode is gebaseerd op het gebruik van speciale Unicode-tekens in codecommentaar die de weergavevolgorde van bidirectionele tekst wijzigen. Met behulp van dergelijke controletekens kunnen sommige delen van de tekst van links naar rechts worden weergegeven, terwijl andere van rechts naar links worden weergegeven. In de dagelijkse praktijk kunnen dergelijke controletekens bijvoorbeeld worden gebruikt om coderegels in het Hebreeuws of Arabisch in een bestand in te voegen. Maar als u regels met verschillende tekstrichtingen op één regel combineert, met behulp van de opgegeven tekens, kunnen tekstpassages die van rechts naar links worden weergegeven, bestaande reguliere tekst overlappen die van links naar rechts wordt weergegeven.
Met deze methode kunt u een kwaadaardige constructie aan de code toevoegen, maar vervolgens de tekst met deze constructie onzichtbaar maken wanneer u de code bekijkt, door de volgende opmerking toe te voegen of binnen de letterlijke tekens, weergegeven van rechts naar links, wat zal leiden tot volledig verschillende karakters worden over de kwaadaardige invoeging heen gelegd. Dergelijke code blijft semantisch correct, maar wordt anders geïnterpreteerd en weergegeven.
Bij het beoordelen van code wordt een ontwikkelaar geconfronteerd met de visuele volgorde van de karakters en ziet hij een niet-verdachte opmerking in een moderne teksteditor, webinterface of IDE, maar de compiler en tolk zullen de logische volgorde van de karakters gebruiken en zullen de kwaadaardige invoeging verwerken zoals deze is, zonder aandacht te besteden aan de bidirectionele tekst in de opmerkingen. Het probleem treft verschillende populaire code-editors (VS Code, Emacs, Atom), evenals interfaces voor het bekijken van code in repositories (GitHub, Gitlab, BitBucket en alle Atlassian-producten).
Er zijn verschillende manieren om de methode te gebruiken om kwaadaardige acties te implementeren: het toevoegen van een verborgen “return” -expressie, die ertoe leidt dat de functie van tevoren wordt voltooid; commentaar geven op expressies die normaal gesproken zichtbaar zouden zijn als geldige constructies (bijvoorbeeld om belangrijke controles uit te schakelen); het toewijzen van andere stringwaarden die tot stringvalidatiefouten leiden.
Een aanvaller kan bijvoorbeeld een wijziging voorstellen die de volgende regel bevat: if access_level != "user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}" {
die in de beoordelingsinterface wordt weergegeven alsof access_level != “user” {// Controleer of admin
Daarnaast is er een andere aanvalsvariant voorgesteld (CVE-2021-42694), geassocieerd met het gebruik van homogliefen, karakters die qua uiterlijk vergelijkbaar zijn, maar verschillen in betekenis en verschillende Unicode-codes hebben (het karakter “ɑ” lijkt bijvoorbeeld op “ a”, “ɡ” - “g”, “ɩ” - “l”). Soortgelijke tekens kunnen in sommige talen worden gebruikt in de namen van functies en variabelen om ontwikkelaars te misleiden. Er kunnen bijvoorbeeld twee functies met niet te onderscheiden namen worden gedefinieerd die verschillende acties uitvoeren. Zonder een gedetailleerde analyse is het niet meteen duidelijk welke van deze twee functies op een specifieke plaats wordt aangeroepen.
Als veiligheidsmaatregel wordt aanbevolen dat compilers, tolken en assemblagetools die Unicode-tekens ondersteunen een fout of waarschuwing weergeven als er ongepaarde controletekens voorkomen in opmerkingen, letterlijke tekenreeksen of ID's die de richting van de uitvoer veranderen (U+202A, U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E en U+200F). Dergelijke tekens moeten ook expliciet worden verboden in de specificaties van programmeertalen en moeten worden gerespecteerd in code-editors en repository-interfaces.
Addendum 1: Er zijn kwetsbaarheidspatches voorbereid voor GCC, LLVM/Clang, Rust, Go, Python en binutils. GitHub, Bitbucket en Jira hebben het probleem ook opgelost. Er wordt gewerkt aan een oplossing voor GitLab. Om problematische code te identificeren, wordt voorgesteld om het commando te gebruiken: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /pad/naar/ bron
Addendum 2: Russ Cox, een van de ontwikkelaars van het Plan 9 OS en de programmeertaal Go, bekritiseerde de buitensporige aandacht voor de beschreven aanvalsmethode, die al lang bekend was (Go, Rust, C++, Ruby) en niet serieus werd genomen . Volgens Cox betreft het probleem vooral de juiste weergave van informatie in code-editors en webinterfaces, wat opgelost kan worden door tijdens de review de juiste tools en code-analyzers in te zetten. Daarom zou het passender zijn om, in plaats van de aandacht te vestigen op speculatieve aanvallen, zich te concentreren op het verbeteren van code- en afhankelijkheidsbeoordelingsprocessen.
Ras Cox is ook van mening dat compilers niet de juiste plaats zijn om het probleem op te lossen, omdat door het verbieden van gevaarlijke symbolen op compilerniveau er een enorme laag aan tools overblijft waarin het gebruik van deze symbolen acceptabel blijft, zoals build-systemen, assemblers, pakketbeheerders en verschillende configuratieparsers en gegevens. Als voorbeeld wordt het Rust-project gegeven, dat de verwerking van LTR/RTL-code in de compiler verbood, maar geen oplossing toevoegde aan de Cargo-pakketbeheerder, die een soortgelijke aanval via het Cargo.toml-bestand mogelijk maakt. Op dezelfde manier kunnen bestanden zoals BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml en require.txt bronnen van aanvallen worden.
Bron: opennet.ru