Дослідники з Кембриджського університету опублікували техніку непомітної підстановки шкідливого коду в вихідні тексти, що рецензуються. Підготовлений метод атаки (CVE-2021-42574) представлений під ім'ям Trojan Source і базується на формуванні тексту по-різному виглядає для компілятора/інтерпретатора і людини, що переглядає код. Приклади застосування методу продемонстровані для різних компіляторів та інтерпретаторів, що постачаються мовами C, C++ (gcc і clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go і Python.
Метод ґрунтується на застосуванні в коментарях до коду спеціальних Unicode-символів, що змінюють порядок відображення двонаправленого тексту. За допомогою подібних символів, що управляють, одні частини тексту можуть виводитися зліва-направо, а інші - праворуч-наліво. У повсякденній практиці подібні символи керування можуть застосовуватися, наприклад, для вставки у файл з кодом рядків івритом або арабською мовою. Але якщо комбінувати рядки з різним напрямком тексту в одному рядку, за допомогою вказаних символів, уривки тексту, що відображаються праворуч-наліво, можуть перекрити звичайний текст, що відображається зліва-направо.
Використовуючи цей метод у код можна додати шкідливу конструкцію, але потім зробити текст з цією конструкцією непомітним при перегляді коду, через додавання в наступному коментарі або всередині літерала символів, що показуються справа-наліво, що призведе до накладення на шкідливу вставку зовсім інших символів. Подібний код залишиться семантично коректним, але по-різному інтерпретуватиметься і відображатиметься.
У процесі рецензування коду розробник зіткнеться з візуальним порядком виведення символів і побачить у сучасному текстовому редакторі, web-інтерфейсі або IDE коментар, що не викликає підозри, але компілятор та інтерпретатор будуть використовувати логічний порядок символів і опрацюють шкідливу вставку як є, не звертаючи увагу на двонаправлене у коментарі. Проблемі схильні різні популярні редактори коду (VS Code, Emacs, Atom), і навіть інтерфейси перегляду коду в репозиторіях (GitHub, Gitlab, BitBucket і всі продукти Atlassian).
Виділяються кілька способів використання методу для реалізації шкідливих дій: додавання прихованого виразу "return", що призводить до завершення виконання функції передчасно; висновок у коментар виразів, які нормально видимі як діючі конструкції (наприклад, для відключення важливих перевірок); присвоєння інших рядкових значень, які призводять до збоїв перевірки рядків.
Наприклад, атакуючий може запропонувати зміну, що включає рядок: if access_level != «user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}» {
яка буде відображена в інтерфейсі для рецензування як if access_level != «user» { // Check if admin
Додатково запропоновано ще один варіант атаки (CVE-2021-42694), пов'язаний з використанням омогліфів, символів, що зовні схожі за накресленням, але відрізняються значенням і мають різні unicode-коди (наприклад, символ ɑ) нагадує «a», «ɡ» - "g", "ɩ" - "l"). Подібні символи можна використовувати деякими мовами в іменах функцій та змінних для введення розробників в оману. Наприклад, можуть бути визначені дві функції з відмінними іменами, що виконують різні дії. Без детального аналізу відразу не зрозуміти, яка з цих двох функцій викликається в конкретному місці.
В якості заходу для захисту рекомендується реалізувати в компіляторах, інтерпретаторах та складальних інструментах, що підтримують Unicode-символи, виведення помилки або попередження за наявності в коментарях, рядкових літералах або ідентифікаторах непарних керуючих символів, що змінюють напрямок виводу (U+202A, U+202 +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 $'[u
Додаток 2: Рас Кокс (Russ Cox), один із розробників ОС Plan 9 та мови програмування Go, розкритикував надмірну увагу до описаного методу атаки, який вже давно відомий (Go, Rust, C++, Ruby) і не сприймався всерйоз. На думку Кокса, проблема в основному стосується правильності відображення інформації в редакторах коду та web-інтерфейсах, вирішується застосуванням коректних інструментів та аналізаторів коду при рецензуванні. Тому замість привернення уваги до умоглядних атак було б правильніше зосередити увагу на покращенні процесів рецензування коду та залежностей.
Рас Кокс також вважає, що компілятори не те місце, де варто усувати проблему, так як заборонивши небезпечні символи на рівні компілятора залишається величезний пласт інструментів, у яких використання даних символів залишається допустимим, таких як системи складання, асемблери, пакетні менеджери та різноманітні парсери конфігурації та даних. Для прикладу наведено проект Rust, який заборонив обробку коду LTR/RTL у компіляторі, але не додав виправлення до пакетного менеджера Cargo, що дозволяє здійснити аналогічну атаку через файл Cargo.toml. Аналогічно джерелами атак можуть стати такі файли, як BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml та requirements.txt.
Джерело: opennet.ru