Trojan Source'i rünnak koodi muutuste sisestamiseks, mis jäävad arendajale märkamatuks

Cambridge'i ülikooli teadlased avaldasid tehnika, mis võimaldab varjatud pahatahtliku koodi sisestamist ülevaatatud lähtefailidesse. Valmistatud rünnakumeetod (CVE-2021-42574) on tuntud nimega Trojan Source ning põhineb teksti kujundamisel, mis näeb välja erinev kompilaatori/interpretatori ja koodi vaatava inimese jaoks. Meetodi rakendamise näited on demonstreeritud erinevate kompilatorite ja interpretatorite jaoks, mis on saadaval keeltele C, C++ (gcc ja clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go ja Python.

Meetod põhineb koodikommentaarides spetsiaalsete Unicode-märkide kasutamisel, mis muudavad kahepoolselt suunatud teksti kuvamise järjekorda. Selliste juhtmärkide abil saab ühe osa tekstist kuvada vasakult paremale ja teise parelt vasakule. Igapäevaelus võib selliseid juhtmärke kasutada näiteks heebrea või araabia keeles kirjutatud ridade lisamiseks koodifaili. Kuid kui kombineerida erineva suunaga stringe ühes reas, võivad paremale suunaga tekstilõigud kattuda juba olemasoleva tavatekstiga, mis kuvatakse vasakult paremale.

Kasutades seda meetodit, saab koodi lisada kahjuliku konstruktsiooni, kuid seejärel muuta selle konstruktsiooniga tekst vaatamisel kodeerituks, lisades sellele järgnevasse kommentaari või liitrea sisse paremale suunaga märke, mis toob kaasa kahjuliku sisestuse ülemise kihina täiesti erinevate märkide. Selline kood jääb semantiliselt korrektseks, kuid seda tõlgendatakse ja kuvatakse erinevalt.

Koodi ülevaatamise protsessis seisab arendaja silmitsi märkide visuaalse väljundkorra ja näeb kaasaegses tekstiredaktoris, veebiliideses või IDE-s kahtlusi äratavat kommentaari, kuid kompilaator ja tõlgendaja kasutavad märkide loogilist järjekorda ning töötlevad pahatahtliku sisendi nii, nagu see on, pööramata tähelepanu kommentaari suunatud tekstile. Probleemiga on seotud erinevad populaarsed koodiredaktorid (VS Code, Emacs, Atom) ning koodi vaatamise liidesed repos (GitHub, Gitlab, BitBucket ja kõik Atlassiani tooted).

Rõhutatakse mitmeid viise meetodi kasutamiseks pahatahtlike tegevuste elluviimiseks: peidetud väljendi "return" lisamine, mis põhjustab funktsiooni enneaegse lõpetamise; kommentaari sisse peidetud väljendite kujundamine, mis näevad normaaltingimustes välja nagu kehtivad konstruktsioonid (näiteks oluliste kontrollide keelamine); muude stringiväärtuste omistamine, mis põhjustavad stringide kontrollimise ebaõnnestumise.

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

mis see kuvatakse liideses ülevaatamiseks nagu if access_level != «user» { // Kontrolli, kas on administraator

Lisaks on välja pakutud veel üks rünnakute variant (CVE-2021-42694), mis on seotud omoglüüfidest, välimuselt sarnastest märkidest, kuid erineva tähenduse ja erinevate unicode-koodidega (näiteks märk «ɑ» sarnaneb «a», «ɡ» — «g», «ɩ» — «l»). Selliseid märke saab mõnes keeles funktsioonide ja muutujate nimedes kasutada arendajate petmiseks. Näiteks võivad olla määratud kaks funktsiooni, mille nimed on eristamatud, kuid mis täidavad erinevaid toiminguid. Ilma põhjalikku analüüsi tegemata pole kohe selge, milline nendest kahest funktsioonist kutsutakse esile antud kohas.

Kaitseks soovitatakse rakendada kompilaatorites, tõlgendustes ja ehitusvahendites, mis toetavad Unicode märke, veateate või hoiatuse väljastamist, kui kommentaarides, stringi literatuurides või identifikaatorites on paarituid juhtimisnähte, 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). Taolised märgid peaksid olema ka programmi keelte spetsifikatsioonides selgelt keelatud ning neid tuleb arvesse võtta koodiredaktorites ja hoidlate haldamise liidestes.

Lisa 1: Haavatavuse kõrvaldamiseks on ette valmistatud parandused GCC, LLVM/Clang, Rust, Go, Python ja binutils jaoks. Probleem on lahendatud ka GitHubis, Bitbucketis ja Jiras. GitLabi jaoks on paranduse ettevalmistamine pooleli. Probleemse koodi tuvastamiseks on soovitatud 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, Plan 9 operatsioonisüsteemi ja Go programmeerimiskeele arendaja, kritiseeris liigset tähelepanu rakendatud rünnakumeetodile, mis on juba pikka aega tuntud (Go, Rust, C++, Ruby) ning ei ole tõsiseltvõetavana käsitletud. Coxi arvates on probleem peamiselt seotud teabe korrektsusega koodiredaktorites ja veebiliidestes, ning see on lahendatav õige tööriistade ja koodianalüsaatorite kasutamisega ülevaatamise ajal. Seega oleks mõistlikum suunata tähelepanu mitte spekulatiivsetele rünnakutele, vaid keskenduda koodide ja sõltuvuste ülevaatusprotsesside parandamisele.

Ras Cox arvab samuti, et kompilaatorid ei ole õige koht probleemide lahendamiseks, kuna ohtlike sümbolite keeldumine kompilaatori tasemel jätab tohutu hulga tööriistu, kus nende sümbolite kasutamine on endiselt lubatud, nagu ehitussüsteemid, assemblerid, paketihaldurid ja erinevad konfiguratsiooni ning andmete analüsaatorid. Näiteks toob ta välja projekti Rust, mis keelas LTR/RTL koodi töötlemise kompilaatoris, kuid ei lisanud parandust paketihaldurisse Cargo, mis võimaldab läbi Cargo.toml faili sarnast rünnakut. Samuti võivad rünnakute allikateks olla failid nagu BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml ja requirements.txt.

Allikas: opennet.ru