Уязвимость в PackageKit, позволяющая получить права root в разных дистрибутивах Linux, оказалась одной из самых показательных за последние годы: формально ошибка выглядит "типовой", но затрагивает массовый компонент, используется во множестве систем и существует уже больше десятилетия.
Что такое Pack2TheRoot (CVE-2026-41651)
В подсистеме PackageKit - это D‑Bus‑прослойка, которая унифицирует работу с различными менеджерами пакетов (APT, DNF, Zypper и др.) - обнаружена уязвимость, получившая название Pack2TheRoot и идентификатор CVE-2026-41651.
Суть проблемы: непривилегированный пользователь может добиться установки или удаления произвольного пакета и, как следствие, получить права суперпользователя (root) на системе. Ошибка присутствует начиная с версии PackageKit 1.0.2, выпущенной ещё в 2014 году, и исправлена только в релизе 1.3.5.
Исследователи из Deutsche Telekom нашли эту уязвимость с помощью AI‑модели Claude Opus, что само по себе примечательно: всё больше реальных, критичных багов в инфраструктурном ПО находятся с участием ИИ-инструментов, а не только классическими аудитами кода.
Масштаб проблемы и затронутые дистрибутивы
PackageKit до сих пор присутствует во многих популярных дистрибутивах, особенно в десктопных редакциях, где через него работает графический центр приложений и система обновлений. Работоспособный эксплоит уже подготовлен и, по заявлениям специалистов, успешно срабатывает на большинстве систем, где запущен PackageKit.
Эксплуатация уязвимости была продемонстрирована на следующих дистрибутивах и версиях:
- Ubuntu Desktop 18.04, 24.04.4, 26.04
- Ubuntu Server 22.04-24.04
- Debian Desktop 13.4
- Rocky Linux Desktop 10.1
- Fedora 43 Desktop и Server
Авторы находки сознательно отложили публикацию детальных технических подробностей и готового к использованию эксплоита, чтобы у разработчиков и пользователей был люфт по времени на установку обновлений. Тем не менее сам факт наличия рабочей атаки уже подтверждён.
Как именно работает уязвимость
Основная причина проблемы - состояние гонки (race condition) в том, как PackageKit обрабатывает флаги транзакций в фоновом процессе. Упрощённо сценарий выглядит так:
1. Непривилегированный пользователь отправляет через D‑Bus запрос на операцию, которая ему официально разрешена - например, установку определённого пакета, разрешённого политиками.
2. PackageKit проходит через стадию авторизации, проверяет права и принимает решение: операция допустима.
3. До того, как транзакция физически стартует (то есть до реального изменения системы), атакующий успевает отправить второй D‑Bus‑запрос.
4. Если этот второй запрос попадает "в окно" между авторизацией и началом выполнения операции, он может изменить флаги и параметры уже разрешённой транзакции.
5. В результате фоновый процесс выполняет установку не исходного, а подменённого пакета или проводит операцию с другими параметрами, чем те, которые прошли проверку.
Таким образом, уже "одобренная" системой транзакция фактически перезаписывается: вместо легитимного пакета можно подставить любой другой, в том числе локальный пакет атакующего.
Почему это ведёт к получению root
Установка пакетов через системный менеджер всегда выполняется с правами root. Если атакующий подсовывает свой пакет, он может включить в него scriptlet (скрипт, связанный с установкой пакета), который автоматически выполнится до, в процессе или после установки.
Это классический путь эскалации привилегий:
- пользователь, формально не имеющий административных прав,
- инициирует "разрешённую" установку пакета,
- подменяет параметры транзакции из‑за состояния гонки,
- заставляет систему установить свой пакет,
- а внутри него запускается произвольный код с правами суперпользователя.
После этого можно:
- добавить себя в группу sudo,
- изменить /etc/sudoers,
- подложить новый setuid‑бинарник,
- внедрить бекдор в системные службы.
Статус исправлений в дистрибутивах
Уязвимость закрыта в версии PackageKit 1.3.5. Производители дистрибутивов по-разному реагируют на подобные проблемы: где-то патчи появляются очень быстро, где-то - с заметной задержкой, особенно в ветках oldstable.
По имеющимся данным:
- в современных ветках крупных десктопных дистрибутивов фиксы уже начали внедрять или подготовили backport‑патчи для более старых версий;
- в ряде старых или консервативных веток обновление PackageKit может быть отложено, либо будет исправлена только эта конкретная ошибка без массового обновления зависимостей.
Пользователям стоит самостоятельно проверить, какую версию PackageKit использует их система, и при возможности обновиться до релизов с патчем или более свежей версии дистрибутива, где уязвимость уже перекрыта.
Насколько серьёзна эта уязвимость на практике
На первый взгляд может показаться, что ничего страшного не происходит: обычный пользователь и так способен устанавливать программы через графические менеджеры, а значит, "и так уже может запускать код". Однако такой аргумент игнорирует ключевой момент: запуск кода с правами обычного пользователя и выполнение произвольных действий от имени root - разные уровни риска.
Уязвимость Pack2TheRoot важна по нескольким причинам:
- нарушает модель безопасности: цепочка "авторизация → выполнение" может быть подменена без повторной проверки;
- позволяет провести тихую эскалацию привилегий, маскируясь под обычную системную транзакцию;
- потенциально пригодна для постэксплуатации - например, злоумышленник уже получил доступ к учётной записи пользователя и с её помощью незаметно повышает свои права.
Аргумент "пользователь и так может ставить пакеты, какая разница, какие" некорректен. Разница в том, что пользователь не должен иметь возможность произвольно менять параметры уже авторизованной root‑операции так, чтобы система выполнила не то, что было проверено политиками безопасности.
PackageKit и разные дистрибутивы: реальное положение дел
Опыт администраторов показывает, что отношение к PackageKit в экосистеме Linux неоднородное. В одних дистрибутивах это ключевой компонент пользовательского опыта, в других - скорее побочный инструмент, который многие стараются обходить.
Примеры из практики:
- В дистрибутивах семейства Ubuntu даже старые ветки часто получают заплатки на уязвимости, включая компоненты, которые формально не входят в зону жёстких обязательств сопровождения. Это делает Ubuntu более предсказуемой с точки зрения закрытия дыр, пусть и ценой иногда агрессивных обновлений.
- В Debian, особенно в ветках oldstable, встречаются ситуации, когда даже в основной секции main определённые пакеты остаются с уязвимостями достаточно долго. Это признают и сами сторонники Debian: в плане скорости реакций на дыры Ubuntu нередко обгоняет более консервативный Debian.
- На практике многие приложения вообще не используют PackageKit напрямую. Так, когда одним из самых популярных дистрибутивов была Ubuntu 12.10, Steam ставил необходимые зависимости для игр через apt-get, минуя PackageKit. Позже Steam стал приносить большинство зависимостей в составе собственных контейнеров и пакетов.
- Типичные проприетарные программы под Linux распространяются в виде DEB или RPM-пакетов с явно прописанными зависимостями. При установке, например, Skype системный менеджер сам подтянет нужные библиотеки вроде qt4-32bit - без участия PackageKit.
В результате возникает ситуация, когда PackageKit есть в системе, но активно используется в основном графическими оболочками, а многие пользователи и разработчики вообще не задумываются, что он делает "под капотом".
Для чего PackageKit всё-таки нужен
Несмотря на скепсис части сообщества, PackageKit решает конкретные задачи:
- единый интерфейс для разных менеджеров пакетов через D‑Bus;
- возможность запускать обновления и установки в консоли и затем "подцепиться" к той же транзакции из графического интерфейса;
- интеграция с web‑панелями администрирования и другими внешними интерфейсами, где требуется централизованно управлять пакетами на удалённых серверах.
Важно, что D‑Bus‑прослойка позволяет избежать конфликтов между несколькими фронтендами. Например, можно начать обновление из консоли, а затем наблюдать за процессом в графическом центре приложений без ошибок блокировки БД пакетов. Аналогично веб-интерфейс управления сервером может безопасно инициировать обновления, полагаясь на те же механизмы.
То есть PackageKit во многом - сервисный, фоновый компонент. И именно поэтому его уязвимость столь критична: процессы, которые "висят в фоне" и имеют доступ к привилегированным операциям, превращаются в отличный вектор атаки, если там появляется состояние гонки или другая логическая ошибка.
Почему "фоновые процессы" - не просто эстетика
Иногда можно услышать мнение: "не надо держать фоновый сервис - не будет и уязвимости". В реальности это упрощение. Современные дистрибутивы строятся вокруг постоянно работающих демонов, которые предоставляют единый интерфейс для множества клиентов. Без этого не получится:
- обеспечить согласованный доступ к системе пакетов из разных инструментов;
- организовать централизованное управление обновлениями;
- выстроить нормальную модель безопасности поверх одной точки принятия решений.
Проблема не в самом факте наличия фонового процесса, а в качестве его реализации и тестирования. Pack2TheRoot - типичный пример того, как относительно небольшой логический дефект в области транзакционной логики превращается в полноценный вектор эскалации привилегий.
Практические рекомендации пользователям и администраторам
Чтобы минимизировать риски, стоит:
1. Проверить версию PackageKit в своей системе и при возможности обновить пакет до версии с исправлением или установить релиз дистрибутива, где уязвимость уже закрыта.
2. На серверах, где PackageKit не нужен, рассмотреть вариант его отключения или удаления, если это не ломает зависимостей. Чем меньше лишних привилегированных сервисов запущено, тем меньше площадь атаки.
3. Жёстче относиться к учёткам обычных пользователей: уязвимость позволяет повысить привилегии только при наличии локального доступа к D‑Bus от имени такого пользователя.
4. Регулярно пересматривать список установленных сервисов и демонов, особенно на критичных системах, удаляя инструменты, которые давно не используются.
Выводы
Уязвимость Pack2TheRoot в PackageKit - показатель того, как долго живущие системные компоненты, однажды внедрённые "для удобства", могут спустя годы превратиться в слабое звено безопасности. Ошибка существует с 2014 года, затрагивает широкий спектр дистрибутивов и позволяет непривилегированному пользователю получить root‑доступ за счёт состояния гонки в логике транзакций.
Даже если в конкретной организации PackageKit не считается критичным компонентом, его наличие в системе уже создаёт дополнительный риск. Поэтому разумная стратегия - своевременное обновление до исправленных версий, осознанное управление установленными сервисами и более трезвый взгляд на фоновые процессы: они не "лишние сами по себе", но требуют не менее серьёзного внимания, чем любой другой элемент инфраструктуры.
