Cambridge'i ülikooli teadlased on avaldanud tehnika pahatahtliku koodi vaikseks sisestamiseks eelretsenseeritud lähtekoodi. Ettevalmistatud ründemeetod (CVE-2021-42574) esitatakse Trooja allika nime all ja põhineb teksti moodustamisel, mis näeb koostaja/tõlgi ja koodi vaataja jaoks erinev välja. Meetodi näiteid on demonstreeritud erinevate kompilaatorite ja tõlgendajate jaoks, mis on saadaval C, C++ (gcc ja clang), C#, JavaScripti (Node.js), Java (OpenJDK 16), Rust, Go ja Python jaoks.
Meetod põhineb spetsiaalsete Unicode'i märkide kasutamisel koodikommentaarides, mis muudavad kahesuunalise teksti kuvamisjärjekorda. Selliste juhtmärkide abil saab mõnda tekstiosa kuvada vasakult paremale, teisi - paremalt vasakule. Igapäevapraktikas saab selliseid juhtmärke kasutada näiteks heebrea või araabiakeelsete koodiridade sisestamiseks faili. Kui aga kombineerite erinevate tekstisuundadega read ühel real, võivad määratud tähemärke kasutades paremalt vasakule kuvatavad tekstilõigud kattuda olemasoleva, vasakult paremale kuvatava tavatekstiga.
Seda meetodit kasutades saate koodile lisada pahatahtliku konstruktsiooni, kuid seejärel muuta selle konstruktsiooniga tekst koodi vaatamisel nähtamatuks, lisades järgmisesse kommentaari või paremalt vasakule näidatud tähemärkide sisse, mis viib täielikult pahatahtlikule sisestusele asetatud erinevad tähemärgid. Selline kood jääb semantiliselt õigeks, kuid seda tõlgendatakse ja kuvatakse erinevalt.
Koodi ülevaatamisel seisab arendaja silmitsi märkide visuaalse järjekorraga ja näeb kaasaegses tekstiredaktoris, veebiliideses või IDE-s mittekahtlast kommentaari, kuid kompilaator ja tõlk kasutavad märkide loogilist järjestust ja töödelda pahatahtlikku sisestust nii, nagu see on, pööramata tähelepanu kommentaarides olevale kahesuunalisele tekstile. Probleem puudutab erinevaid populaarseid koodiredaktoreid (VS Code, Emacs, Atom), aga ka hoidlates koodi vaatamise liideseid (GitHub, Gitlab, BitBucket ja kõik Atlassiani tooted).
Meetodit saab pahatahtlike toimingute rakendamiseks kasutada mitmel viisil: peidetud "tagasi" avaldise lisamine, mis viib funktsiooni ennetähtaegse lõpetamiseni; tavaliselt kehtivate konstruktsioonidena nähtavate avaldiste kommenteerimine (näiteks oluliste kontrollide keelamiseks); muude stringiväärtuste määramine, mis põhjustavad stringi valideerimise tõrkeid.
Näiteks võib ründaja pakkuda välja muudatuse, mis sisaldab rida: if access_level != "user{U+202E} {U+2066}// Kontrollige, kas admin{U+2069} {U+2066}" {
mis kuvatakse ülevaatuse liideses justkui juurdepääsu_tase != “kasutaja” { // Kontrollige, kas admin
Lisaks on pakutud välja veel üks ründevariant (CVE-2021-42694), mis on seotud homoglüüfide kasutamisega, märkidega, mis on välimuselt sarnased, kuid tähenduselt erinevad ja millel on erinevad unicode koodid (näiteks märk “ɑ” meenutab “ a”, “ɡ” - “g”, “ɩ” - “l”). Sarnaseid märke saab mõnes keeles kasutada funktsioonide ja muutujate nimedes, et arendajaid eksitada. Näiteks võib määratleda kaks eristamatu nimega funktsiooni, mis täidavad erinevaid toiminguid. Ilma üksikasjaliku analüüsita pole kohe selge, kumba neist kahest funktsioonist konkreetses kohas kutsutakse.
Turvameetmena on soovitatav, et Unicode'i märke toetavad kompilaatorid, interpretaatorid ja koostetööriistad kuvaksid veateate või hoiatuse, kui kommentaarides, stringiliteraalides või identifikaatorites, 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 selgesõnaliselt keelatud ka programmeerimiskeele spetsifikatsioonides ning neid tuleks austada koodiredaktorites ja hoidla liidestes.
Lisa 1: GCC, LLVM/Clang, Rust, Go, Python ja binutils jaoks on ette valmistatud haavatavuse paigad. GitHub, Bitbucket ja Jira lahendasid ka probleemi. GitLabi parandamine on pooleli. Probleemse koodi tuvastamiseks on soovitatav kasutada käsku: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/ allikas
Lisa 2: Russ Cox, üks Plan 9 OS-i ja programmeerimiskeele Go arendajatest, kritiseeris liigset tähelepanu kirjeldatud ründemeetodile, mis on ammu tuntud (Go, Rust, C++, Ruby) ja mida ei võetud tõsiselt. . Coxi sõnul puudutab probleem peamiselt info korrektset kuvamist koodiredaktorites ja veebiliidestes, mida saab lahendada õigete tööriistade ja koodianalüsaatorite kasutamisega ülevaatuse käigus. Seetõttu oleks spekulatiivsetele rünnakutele tähelepanu juhtimise asemel õigem keskenduda koodi ja sõltuvuse ülevaatuse protsesside täiustamisele.
Ras Cox usub ka, et kompilaatorid ei ole probleemi lahendamiseks õige koht, kuna ohtlike sümbolite keelamisega kompilaatori tasemel jääb alles tohutu hulk tööriistu, milles nende sümbolite kasutamine on vastuvõetav, näiteks süsteemide ehitamine, komplekteerijad, paketihaldurid ning erinevad konfiguratsiooniparserid ja andmed. Näitena on toodud projekt Rust, mis keelas kompilaatoris LTR/RTL koodi töötlemise, kuid ei lisanud Cargo paketihaldurile parandust, mis võimaldab sarnast rünnet läbi Cargo.toml faili. Sarnaselt võivad ründeallikateks saada sellised failid nagu BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml ja requirements.txt.
Allikas: opennet.ru