Trojan Source атака за въвеждане на промени в кода, които са невидими за разработчика

Изследователи от университета в Кеймбридж публикуваха техника за тихо вмъкване на зловреден код в рецензиран изходен код. Подготвеният метод за атака (CVE-2021-42574) е представен под името Trojan Source и се основава на формирането на текст, който изглежда различно за компилатора/интерпретатора и лицето, което преглежда кода. Примери за метода са демонстрирани за различни компилатори и интерпретатори, доставени за C, C++ (gcc и clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go и Python.

Методът се основава на използването на специални Unicode символи в коментарите на кода, които променят реда на показване на двупосочен текст. С помощта на такива контролни знаци някои части от текста могат да се показват отляво надясно, а други - отдясно наляво. В ежедневната практика такива контролни знаци могат да се използват например за вмъкване на кодови редове на иврит или арабски във файл. Но ако комбинирате редове с различни посоки на текст в един ред, като използвате посочените знаци, пасажите от текст, показани отдясно наляво, могат да припокрият съществуващ обикновен текст, показан отляво надясно.

Използвайки този метод, можете да добавите злонамерена конструкция към кода, но след това да направите текста с тази конструкция невидим, когато преглеждате кода, като добавите в следния коментар или вътре буквалните знаци, показани отдясно наляво, което ще доведе до напълно различни знаци се наслагват върху злонамереното вмъкване. Такъв код ще остане семантично правилен, но ще бъде интерпретиран и показан по различен начин.

Докато преглежда кода, разработчикът ще се сблъска с визуалния ред на знаците и ще види неподозрителен коментар в модерен текстов редактор, уеб интерфейс или IDE, но компилаторът и интерпретаторът ще използват логическия ред на знаците и ще обработете злонамереното вмъкване такова, каквото е, без да обръщате внимание на двупосочния текст в коментарите. Проблемът засяга различни популярни редактори на код (VS Code, Emacs, Atom), както и интерфейси за преглед на код в хранилища (GitHub, Gitlab, BitBucket и всички продукти на Atlassian).

Има няколко начина за използване на метода за прилагане на злонамерени действия: добавяне на скрит израз „връщане“, което води до завършване на функцията преди време; коментиране на изрази, които обикновено биха били видими като валидни конструкции (например за деактивиране на важни проверки); присвояване на други стойности на низ, които водят до неуспешно валидиране на низ.

Например, атакуващ може да предложи промяна, която включва реда: if access_level != "user{U+202E} {U+2066}// Проверете дали admin{U+2069} {U+2066}" {

което ще се покаже в интерфейса за преглед, сякаш access_level != “user” { // Проверете дали администратор

Освен това е предложен друг вариант на атака (CVE-2021-42694), свързан с използването на хомоглифи, знаци, които са подобни на външен вид, но се различават по значение и имат различни уникод кодове (например знакът „ɑ“ прилича на „ a”, “ɡ” - “g”, “ɩ” - “l”). Подобни знаци могат да се използват на някои езици в имената на функции и променливи, за да подведат разработчиците. Например могат да бъдат дефинирани две функции с неразличими имена, които изпълняват различни действия. Без подробен анализ не е веднага ясно коя от тези две функции се извиква на конкретно място.

Като мярка за сигурност се препоръчва компилаторите, интерпретаторите и инструментите за асемблиране, които поддържат Unicode символи, да показват грешка или предупреждение, ако има несдвоени контролни знаци в коментари, низови литерали или идентификатори, които променят посоката на изхода (U+202A, U+202B, U +202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E и U+200F). Такива знаци също трябва да бъдат изрично забранени в спецификациите на езика за програмиране и трябва да се спазват в редакторите на кодове и интерфейсите на хранилищата.

Допълнение 1: Подготвени са пачове за уязвимости за GCC, LLVM/Clang, Rust, Go, Python и binutils. GitHub, Bitbucket и Jira също коригираха проблема. В ход е корекция за GitLab. За идентифициране на проблемния код се препоръчва да използвате командата: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/ източник

Допълнение 2: Ръс Кокс, един от разработчиците на ОС Plan 9 и езика за програмиране Go, критикува прекомерното внимание към описания метод на атака, който отдавна е известен (Go, Rust, C++, Ruby) и не се приема на сериозно . Според Кокс проблемът се отнася главно до правилното показване на информация в редакторите на кодове и уеб интерфейсите, което може да бъде разрешено чрез използване на правилните инструменти и анализатори на код по време на преглед. Следователно, вместо да привличаме вниманието към спекулативни атаки, би било по-подходящо да се съсредоточим върху подобряването на процесите за преглед на кода и зависимостите.

Рас Кокс също вярва, че компилаторите не са правилното място за отстраняване на проблема, тъй като чрез забраната на опасни символи на ниво компилатор, остава огромен слой от инструменти, в които използването на тези символи остава приемливо, като системи за изграждане, асемблери, мениджъри на пакети и различни анализатори на конфигурация и данни. Като пример е даден проектът Rust, който забрани обработката на LTR/RTL код в компилатора, но не добави корекция на Cargo пакетния мениджър, който позволява подобна атака през файла Cargo.toml. По подобен начин файлове като BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml и requirements.txt могат да станат източници на атаки.

Източник: opennet.ru