Esploristoj de la Universitato de Kembriĝo publikigis teknikon por silente enmeti malican kodon en kun-reviziitan fontkodon. La preta atakmetodo (CVE-2021-42574) estas prezentita sub la nomo Troja Fonto kaj baziĝas sur la formado de teksto kiu aspektas malsama por la kompililo/interpretisto kaj la persono rigardanta la kodon. Ekzemploj de la metodo estas pruvitaj por diversaj kompililoj kaj interpretistoj provizitaj por C, C++ (gcc kaj clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go kaj Python.
La metodo baziĝas sur la uzo de specialaj Unikodaj signoj en kodkomentoj kiuj ŝanĝas la montran ordon de dudirekta teksto. Helpe de tiaj kontrolsignoj, iuj partoj de la teksto povas esti montrataj de maldekstre dekstren, dum aliaj - de dekstre maldekstren. En ĉiutaga praktiko, tiaj kontrolsignoj povas esti uzataj, ekzemple, por enmeti kodliniojn en la hebrea aŭ araba en dosieron. Sed se vi kombinas liniojn kun malsamaj tekstaj direktoj en unu linio, uzante la specifitajn signojn, fragmentoj de teksto montritaj de dekstre al maldekstre povas interkovri ekzistantan regulan tekston montritan de maldekstre dekstren.
Uzante ĉi tiun metodon, vi povas aldoni malican konstruaĵon al la kodo, sed poste igi la tekston kun ĉi tiu konstruo nevidebla kiam vi vidas la kodon, aldonante en la sekva komento aŭ ene de la laŭvortaj signoj montritaj de dekstre al maldekstre, kio kondukos al komplete. malsamaj signoj supermetitaj al la malica enmeto. Tia kodo restos semantike ĝusta, sed estos interpretita kaj montrata alimaniere.
Reviziante kodon, programisto konfrontiĝos kun la vida ordo de la signoj kaj vidos nesuspektindan komenton en moderna tekstredaktilo, retinterfaco aŭ IDE, sed la kompililo kaj interpretisto uzos la logikan ordon de la signoj kaj faros prilabori la malican enmeton kiel estas, sen atenti la dudirektan tekston en la komentoj. La problemo influas diversajn popularajn kodredaktilojn (VS Code, Emacs, Atom), kaj ankaŭ interfacojn por vidi kodon en deponejoj (GitHub, Gitlab, BitBucket kaj ĉiuj Atlassian-produktoj).
Estas pluraj manieroj uzi la metodon por efektivigi malicajn agojn: aldonante kaŝitan "revenan" esprimon, kiu kondukas al la kompletiĝo de la funkcio antaŭtempe; komentante esprimojn kiuj normale estus videblaj kiel validaj konstrukcioj (ekzemple, por malŝalti gravajn kontrolojn); asignante aliajn kordvalorojn kiuj kondukas al kordvalidigaj fiaskoj.
Ekzemple, atakanto povus proponi ŝanĝon kiu inkluzivas la linion: if access_level != "uzanto{U+202E} {U+2066}// Kontrolu ĉu administranto{U+2069} {U+2066}" {
kiu estos montrata en la revizia interfaco kvazaŭ access_level != "uzanto" { // Kontrolu ĉu administranto
Aldone, alia atakvariaĵo estis proponita (CVE-2021-42694), asociita kun la uzo de homoglifoj, karakteroj kiuj estas similaj laŭ aspekto, sed malsamas laŭ signifo kaj havas malsamajn unikodajn kodojn (ekzemple, la signo "ɑ" similas " a”, “ɡ” - “g”, “ɩ” - “l”). Similaj signoj povas esti uzataj en iuj lingvoj en la nomoj de funkcioj kaj variabloj por trompi programistojn. Ekzemple, du funkcioj kun nedistingeblaj nomoj povas esti difinitaj kiuj plenumas malsamajn agojn. Sen detala analizo, estas ne tuj klare, kiu el ĉi tiuj du funkcioj estas nomita en specifa loko.
Kiel sekureciniciato, estas rekomendite ke kompililoj, interpretistoj kaj kunigiloj kiuj subtenas Unikodajn signojn montras eraron aŭ averton se estas neparigitaj kontrolsignoj en komentoj, ĉenliteraĵoj aŭ identigiloj kiuj ŝanĝas la direkton de eligo (U+202A, U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E kaj U+200F). Tiaj signoj ankaŭ devus esti eksplicite malpermesitaj en programlingvospecifoj kaj devus esti respektataj en kodredaktiloj kaj deponejo-interfacoj.
Aldono 1: Vundeblaj diakiloj estis preparitaj por GCC, LLVM/Clang, Rust, Go, Python kaj binutils. GitHub, Bitbucket kaj Jira ankaŭ riparis la problemon. Riparo por GitLab estas en progreso. Por identigi probleman kodon, oni sugestas uzi la komandon: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/ fonto
Aldono 2: Russ Cox, unu el la programistoj de la Plan 9 OS kaj la programlingvo Go, kritikis la troan atenton al la priskribita atakmetodo, kiu estas delonge konata (Go, Rust, C++, Ruby) kaj ne estis prenita serioze. . Laŭ Cox, la problemo ĉefe koncernas la ĝustan montradon de informoj en kodredaktiloj kaj retinterfacoj, kiuj povas esti solvitaj uzante la ĝustajn ilojn kaj kodanalizilojn dum revizio. Tial, anstataŭ atentigi pri konjektaj atakoj, estus pli konvene koncentriĝi pri plibonigo de kodo kaj dependecaj reviziaj procezoj.
Ras Cox ankaŭ opinias, ke kompililoj ne estas la ĝusta loko por ripari la problemon, ĉar malpermesante danĝerajn simbolojn ĉe la kompilila nivelo, restas grandega tavolo da iloj, en kiuj la uzo de ĉi tiuj simboloj restas akceptebla, kiel konstrusistemoj, asembleroj, pakaĵmanaĝeroj kaj diversaj agordaj analiziloj kaj datumoj. Ekzemple, la Rust-projekto estas donita, kiu malpermesis la prilaboradon de LTR/RTL-kodo en la kompililo, sed ne aldonis solvon al la Cargo-pakaĵmanaĝero, kiu permesas similan atakon per la Cargo.toml-dosiero. Simile, dosieroj kiel BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml kaj requirements.txt povas fariĝi fontoj de atakoj.
fonto: opennet.ru