Trojan Source rünnak koodi muutmise sisestamiseks, mis on arendajale märkamatud

Cambridge Ülikooli teadlased avaldasid tehnika pahatahtliku koodi peidetud sisestamiseks arvustatud lähtekoodidesse. Rünnaku ettevalmistatud meetod (CVE-2021-42574) esitatakse nimega Trojan Source ja see põhineb tekstide moodustamisel, mis näevad silmale ning kompilaatorile / tõlgile erinevad välja. Meetodi rakendamise näited on demonstreeritud erinevate kompilaatorite ja tõlgendajate jaoks, nagu C, C++ (gcc ja clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go ja Python.

Meetod põhineb spetsiaalsete Unicode-märkide kasutamisel koodikommentaarides, mis muudavad kahepoolselt suunatud teksti kuvamise järjekorda. Selliste juhtmärkide abil võivad ühed tekstijupid olla kuvatud vasakult paremale, teised aga paremalt vasakule. Igapäevases praktikas võivad sellised juhtmärkide kombineerimised olla näiteks vajalikud heebrea või araabia keeles koodi failidesse lisamiseks. Kuid kui kombineerida erineva suunaga tekstirida ühes ja samas real nende märkide abil, võivad paremale avanevad tekstilõigud katab olemasolevat tavalist teksti, mis on kuvatud vasakult paremale.

Selle meetodi abil saab koodi lisada pahatahtliku konstruktsiooni, kuid seejärel saab muuta selle konstruktsiooni nähtamatuks koodi vaatamisel, lisades sellele järgnevasse kommentaaridesse või sisemisse literali sümboleid, mis kuvatakse paremalt vasakule, mis toob endaga kaasa, et pahataht kvaliteet jääb täiesti teistsuguste märkide varju. Selline kood jääb semantiliselt korrektseks, kuid seda tõlgendatakse ja kuvatakse erinevalt.

Koodi ülevaatamise käigus puutub arendaja kokku sümbolite visuaalse väljundjärjekorraga ja näeb tänapäevases tekstiredaktorites, veebiliidestes või IDEs kahtlust tekitamata kommentaari, kuid kompilaator ja tõlgendaja kasutavad sümbolite loogilist järjekorda ning töötlevad pahatahtliku sisestuse sellisena, ignoreerides kommentaarides olevat kahepoolselt suunatud teksti. Oht on mitmesugustes populaarsetes koodiredaktorites (VS Code, Emacs, Atom), samuti koodide vaatamise liidestes hoidlates (GitHub, Gitlab, BitBucket ja kõik Atlassiani tooted).

Mitmed meetodid, millega saab kasutada kahjulikke toiminguid, hõlmavad järgmisi: varjatud „return“ väljendi lisamine, mis lõpetab funktsiooni täitmise liiga vara; kommentaaridesse peidetud konstruktsioonid, mis näivad normaalselt toimivat (näiteks oluliste kontrollide keelamiseks); ja teiste stringiväärtuste määramine, mis põhjustavad stringide kontrolli ebaõnnestumise.

Näiteks võib ründaja pakkuda muudatust, mis sisaldab järgmist rida: if access_level != "user{U+202E} {U+2066}\/\/ Check if admin{U+2069} {U+2066}" {

mis kuvatakse liideses ülevaatamiseks kui if access_level != "user" { \/\/ Check if admin

Täiendavalt on ette pandud veel üks rünnaku variant (CVE-2021-42694), mis on seotud omogliphide kasutamisega, need on märgid, mis näivad sarnased, kuid erinevad tähenduse ja unicode-koodide poolest (näiteks märk "ɑ" sarnaneb "a"-le, "ɡ" - "g"-le, "ɩ" - "l"-ile). Selliseid märke saab kasutada mõnedes keeltes funktsioonide ja muutuja nimedes, et arendajaid petta. Näiteks saab defineerida kaks funktsiooni, mille nimed on eristamatud, kuid mis teevad erinevaid toiminguid. Ilma detailse analüüsita ei saa kohe aru, millist neist kahest funktsioonist kutsutakse konkreetses kohas.

Kaitsemeetmena soovitatakse rakendada kompilaatoreis, tõlgendustes ja koostamisvahendites, mis toetavad Unicode märke, viga või hoiatust, kui kommentaarides, stringides või identifikaatorites on paaritus kontrollmärke, mis muudavad väljundi suunda (U+202A, U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E ja U+200F). Sellised märgid peaksid olema selgelt keelatud ka programmeerimiskeelte spetsifikatsioonides ning need peaksid olema arvesse võetud koodiredaktorites ja ladustamisliideses.

Täiendav teave 1: Haavatavuse kõrvaldamiseks on parandused valmistatud GCC, LLVM/Clang, Rust, Go, Python ja binutils jaoks. Probleem on samuti lahendatud GitHubis, Bitbucketis ja Jiras. GitLabi jaoks on parandamise ettevalmistamine käimas. Probleemse koodi tuvastamiseks on soovitatav kasutada käsku: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' \/path\/to\/source

Täiendav 2: Russ Cox, üks Plan 9 operatsioonisüsteemi ja Go programmeerimiskeele arendajatest, kritiseeris liigset tähelepanu rünnakumeetodile, mis on juba ammu tuntud (Go, Rust, C++, Ruby) ja mida ei võetud tõsiselt. Koxi arvates on probleem enamasti seotud teabe kuvamise õigusega koodiredaktorites ja veebiliideses, mida saab lahendada nõuetekohaste tööriistade ja koodianalüsaatorite kasutamisega ülevaatusprotsessides. Seetõttu oleks õiglasem suunata tähelepanu koodide ja sõltuvuste ülevaatusprotsesside parendamisele, mitte abstraktsetele rünnakutele.

Russ Cox usub ka, et kompilaatorid ei ole see koht, kus probleemi lahendada, kuna keelates ohtlikud sümbolid kompilaatori tasandil jääb tohutult tööriistu, kus nende sümbolite kasutamine jääb lubatuks, nagu kogumisse süsteemid, assemblerid, paketihaldurid ning erinevad konfiguratsiooni- ja andmearvutid. Näiteks on projekt Rust keelanud LTR/RLT koodi töötlemise kompilaatoris, kuid ei ole lisanud parandust paketihaldurisse Cargo, mis lubab sama rünnaku teostada faili Cargo.toml kaudu. Sarnased rünnakute allikad võivad olla ka sellised failid nagu BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml ja requirements.txt.

Allikas: opennet.ru