Kembric Universitetinin tədqiqatçıları zərərli kodun yoxlanılan mənbə koduna səssizcə daxil edilməsi texnikasını dərc ediblər. Hazırlanmış hücum metodu (CVE-2021-42574) Trojan Source adı altında təqdim olunur və tərtibçi/tərcüməçi və koda baxan şəxs üçün fərqli görünən mətnin formalaşmasına əsaslanır. Metodun nümunələri C, C++ (gcc və clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go və Python üçün təchiz edilmiş müxtəlif kompilyatorlar və tərcüməçilər üçün nümayiş etdirilir.
Metod iki istiqamətli mətnin göstərilməsi qaydasını dəyişən kod şərhlərində xüsusi Unicode simvollarının istifadəsinə əsaslanır. Belə nəzarət simvollarının köməyi ilə mətnin bəzi hissələri soldan sağa, digərləri isə sağdan sola göstərilə bilər. Gündəlik təcrübədə bu cür nəzarət simvollarından, məsələn, fayla ivrit və ya ərəb dilində kod sətirləri daxil etmək üçün istifadə edilə bilər. Fərqli mətn istiqamətləri olan sətirləri bir sətirdə birləşdirsəniz, göstərilən simvollardan istifadə edərək, sağdan sola göstərilən mətnin keçidləri soldan sağa göstərilən mövcud adi mətni üst-üstə düşə bilər.
Bu üsuldan istifadə edərək, koda zərərli konstruksiya əlavə edə bilərsiniz, lakin sonra aşağıdakı şərhə və ya sağdan sola göstərilən hərfi simvolların içərisinə əlavə etməklə koda baxarkən bu konstruksiya ilə mətni görünməz edə bilərsiniz ki, bu da tamamilə müxtəlif simvollar zərərli daxiletmənin üzərinə qoyulur. Belə kod semantik olaraq düzgün qalacaq, lakin fərqli şəkildə şərh ediləcək və göstəriləcək.
Kodları nəzərdən keçirərkən tərtibatçı simvolların vizual ardıcıllığı ilə qarşılaşacaq və müasir mətn redaktorunda, veb interfeysində və ya IDE-də şübhəli olmayan şərhi görəcək, lakin tərtibçi və tərcüməçi simvolların məntiqi ardıcıllığından istifadə edəcək və şərhlərdə iki istiqamətli mətnə fikir vermədən zərərli daxiletməni olduğu kimi emal edin. Problem müxtəlif populyar kod redaktorlarına (VS Code, Emacs, Atom), həmçinin depolarda (GitHub, Gitlab, BitBucket və bütün Atlassian məhsulları) kodlara baxmaq üçün interfeyslərə təsir göstərir.
Zərərli hərəkətləri həyata keçirmək üçün metoddan istifadə etməyin bir neçə yolu var: funksiyanın vaxtından əvvəl tamamlanmasına səbəb olan gizli "qaytarma" ifadəsinin əlavə edilməsi; normal olaraq etibarlı konstruksiyalar kimi görünən ifadələri şərh etmək (məsələn, vacib yoxlamaları aradan qaldırmaq üçün); sətir doğrulama uğursuzluğuna səbəb olan digər sətir dəyərlərinin təyin edilməsi.
Məsələn, təcavüzkar sətri ehtiva edən dəyişiklik təklif edə bilər: if access_level != "user{U+202E} {U+2066}// Admin{U+2069} {U+2066}" {
Baxış interfeysində sanki access_level kimi göstəriləcək != “user” { // Admin olub olmadığını yoxlayın
Bundan əlavə, homoqliflərin istifadəsi ilə əlaqəli başqa bir hücum variantı təklif edilmişdir (CVE-2021-42694), görünüşü oxşar olan, lakin mənaca fərqlənən və fərqli unicode kodlarına malik simvollar (məsələn, “ɑ” simvolu “ a”, “ɡ” - “g”, “ɩ” - “l”). Oxşar simvollar bəzi dillərdə tərtibatçıları çaşdırmaq üçün funksiyaların və dəyişənlərin adlarında istifadə edilə bilər. Məsələn, fərqli hərəkətləri yerinə yetirən, fərqlənməyən adları olan iki funksiya müəyyən edilə bilər. Ətraflı təhlil olmadan, bu iki funksiyadan hansının müəyyən bir yerdə çağırıldığı dərhal aydın deyil.
Təhlükəsizlik tədbiri olaraq, şərhlərdə, sətir hərflərində və ya çıxış istiqamətini dəyişən identifikatorlarda qoşalaşdırılmamış nəzarət simvolları varsa, Unicode simvollarını dəstəkləyən kompilyatorlara, tərcüməçilərə və montaj alətlərinə xəta və ya xəbərdarlıq göstərməsi tövsiyə olunur (U+202A, U+202B, U +202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E və U+200F). Bu cür simvollar proqramlaşdırma dilinin spesifikasiyalarında da açıq şəkildə qadağan edilməli və kod redaktorları və repozitor interfeyslərində onlara hörmət edilməlidir.
Əlavə 1: GCC, LLVM/Clang, Rust, Go, Python və binutils üçün zəiflik yamaqları hazırlanmışdır. GitHub, Bitbucket və Jira da problemi həll etdi. GitLab üçün düzəliş davam edir. Problemli kodu müəyyən etmək üçün aşağıdakı əmrdən istifadə etmək tövsiyə olunur: grep -r $'[\u061C\u200E\u200F\u202A\u202C\u202D\u202E\u202\u2066\u2067\u2068\u2069\uXNUMX]'/ mənbə
Əlavə 2: Plan 9 ƏS və Go proqramlaşdırma dilinin tərtibatçılarından biri olan Russ Cox, çoxdan məlum olan (Go, Rust, C++, Ruby) təsvir edilən hücum metoduna həddindən artıq diqqəti tənqid etdi və ciddiyə alınmadı. . Koksun sözlərinə görə, problem əsasən kod redaktorlarında və veb-interfeyslərdə məlumatın düzgün göstərilməsi ilə bağlıdır ki, bu da nəzərdən keçirilərkən düzgün alətlərdən və kod analizatorlarından istifadə etməklə həll edilə bilər. Buna görə də diqqəti spekulyativ hücumlara cəlb etmək əvəzinə, kodun və asılılığın nəzərdən keçirilməsi proseslərinin təkmilləşdirilməsinə diqqət yetirmək daha məqsədəuyğun olardı.
Ras Cox həmçinin hesab edir ki, kompilyatorlar problemi həll etmək üçün düzgün yer deyil, çünki kompilyator səviyyəsində təhlükəli simvolları qadağan etməklə, bu simvolların istifadəsinin məqbul qaldığı nəhəng alətlər təbəqəsi qalır, məsələn, qurma sistemləri, montajçılar, paket menecerləri və müxtəlif konfiqurasiya təhlilçiləri və məlumatları. Nümunə olaraq, kompilyatorda LTR/RTL kodunun işlənməsini qadağan edən, lakin Cargo.toml faylı vasitəsilə oxşar hücuma imkan verən Cargo paket menecerinə düzəliş əlavə etməyən Rust layihəsi verilmişdir. Eynilə, BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml və requirements.txt kimi fayllar hücum mənbəyinə çevrilə bilər.
Mənbə: opennet.ru