Бэкдор в библиотеке liblzma

Проект LZMA Utils, а позднее XZ Utils, появился в 2005 году и был разработан командой дистрибутива Tukaani (форк Slackware). Основной задачей было заменить алгоритм gzip, что позволило бы уместить дистрибутив на болванку в 700 Мбайт. С тех пор прошло 19 лет и xz-utils есть во всех современных дистрибутивах. Поэтому для сообщества свободного ПО стало настоящим шоком обнаружение бэкдора в библиотеке liblzma.

Детальное описание можно найти в статье OpenNET "В библиотеке xz/liblzma выявлен бэкдор, организующий вход через sshd". Если коротко, то суть в том, что в библиотеку liblzma внедрили бэкдор, который при загрузке этой библиотеки в память внедряет хук на вызовы функции, и когда происходит вызов функции с именем  RSA_public_decrypt@ , который в частности используется в коде sshd, отвечающим за предаутентификацию при соединении, выполняются какие-то действия, вероятно, позволяющие получить доступ без аутентификации к системе при определённых условиях. Это стало возможным благодаря тому, что в некоторых дистрибутивах в openssh добавляется патч для поддержки нотификаций от libsystemd, а уже libsystemd линкуется с liblzma. Это Debian, Fedora и другие.

Бэкдор есть в liblzma версии 5.6.0  и 5.6.1, которые ещё не успели попасть в стабильные дистрибутивы, но попали в нестабильные ветки Debian Sid, Fedora и другие. Бэкдор был обнаружен из-за его не очень качественной реализации, которая приводила к замедлению работы и частым ошибкам при работе с памятью. Когда стали раскапывать причины, обнаружили всю мякотку. При этом один из разработчиков пытался "фиксить" эти баги, чтобы лучше скрыть бэкдор. Активно переписывался с майнтейнерами Debian и Fedora, чтобы побыстрее включить новую версию в дистрибутивы. Это сразу навело на мысль о том, что это не взлом инфраструктуры проекта XZ, а то, что один из разработчиков ведёт двойную игру.
Бэкдор был очень искусно скрыт, так как не было его исходного кода, а его включение происходило при сборке пакетов deb/rpm из бинарных "тестовых" файлов, которые даже не включались в git-репозиторий, но были в тарболе. Сейчас уже практически все вендоры оперативно отреагировали и откатили xz до версии без бэкдора.

Сейчас все проекты Tukaani на github были заблокированы. Аккаунт разработчика Jia Tan <jiat0218@gmail.com>, который присоединился два года назад, тоже заблокировали. Теперь будут проверять код, который он за два года успел навтыкать по другим проектам. Обнаружили, что он пытался протолкнуть свои патчи в ядро через проект xz-embedded под предлогом того, чтобы для встроенных систем сделать встроенный архиватор xz в ядре. Наверно, чтобы в будущем холодильники или микроволновки могли подрабатывать в бот-фермах для DDoS-атак.  Активно начались поиски индивида. Пока понятно, что он всегда использовал VPN и скрывал свою временную зону в чатах. Вероятно в ближайшее время могут раскопать что-то ещё.

История показывает то, насколько серьёзно нужно относится к источникам ПО и то, что, к сожалению, доверять нынче нельзя никому.

P.S. Разбор ситуации идёт в непрерывном режиме и появляется больше любопытных деталей. Хорошо и доступно материал излагается на opennet:

1. Ретроспектива продвижения бэкдора в пакет xz - как использовалась социальная инженерия для захвата опенсорс проекта xz и внедрение зловредного кода
2. Разбор логики активации и работы бэкдора в пакете xz - предварительные результаты реверс-инжиниринга бэкдора, которые показывают ещё более страшную картину. Бэкдор не используется для обхода аутентификации, а это полноценный RCE - удалённое выполнение кода, когда при подключении по ssh и обмене ключами ssh-сервер просто выполняет присланный код с правами root от клиента имеющего определённый отпечаток публичного ключа. Т.о. в журнале хоста не будет даже никаких событий входа по ssh, а хост окажется под контролем атакующего. Причём нет никакой возможности отключить в конфигурации sshd загрузку клиентского сертификата, отправленного атакующем. Правда в бэкдоре обнаружен killswitch (отключение работы бэкдора), бэкдор не сработает если выставлена переменная окружения "yolAbejyiejuvnup=Evjtgvsh5okmkAvj" у процесса sshd.