Исследователи из Кембриджского университета опубликовали технику незаметной подстановки вредоносного кода в рецензируемые исходные тексты. Подготовленный метод атаки (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", приводящего к завершению выполнения функции раньше времени; заключение в комментарий выражений, нормальным образом видимых как действующие конструкции (например, для отключения важных проверок); присвоение иных строковых значений, приводящих к сбоям проверки строк.
Например, атакующий может предложить изменение, включающее строку:
которая будет отображена в интерфейсе для рецензирования как
Дополнительно предложен ещё один вариант атаки (CVE-2021-42694), связанный с использованием омоглифов, символов, внешне похожих по начертанию, но отличающихся значением и имеющих разные unicode-коды (например, символ "ɑ" напоминает "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). Подобные символы также должны быть явно запрещены в спецификациях языков программирования и должны учитываться в редакторах кода и интерфейсах для работы с репозиториями.
Дополнение: Исправления с устранением уязвимости подготовлены для GCC, LLVM/Clang, Rust, Python и binutils. Проблему также устранили GitHub, Bitbucket и Jira. В процессе подготовки исправление для GitLab. Для выявления проблемного кода предложено использовать команду:
Метод основан на применении в комментариях к коду специальных 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+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E и U+200F). Подобные символы также должны быть явно запрещены в спецификациях языков программирования и должны учитываться в редакторах кода и интерфейсах для работы с репозиториями.
Дополнение: Исправления с устранением уязвимости подготовлены для GCC, LLVM/Clang, Rust, Python и binutils. Проблему также устранили GitHub, Bitbucket и Jira. В процессе подготовки исправление для GitLab. Для выявления проблемного кода предложено использовать команду:
Код:
grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/source