Citrix закрыла в XenServer подбор Pool Secret и повышение прав через роли RBAC

Citrix выпустила обновление безопасности для XenServer 8.4 и XenServer 9. Одна из ошибок позволяет атакующему без учётной записи, но с доступом к сети управления, постепенно восстановить Pool Secret - служебный токен, которым хосты пула аутентифицируют запросы друг друга, - и получить полный контроль над пулом. Ещё пять проблем в системе ролей RBAC позволяют поднять права до pool-admin. Обновления выложены в каналы Early Access и Normal, бюллетень CTX697316 от 10 ноября 2026 года закрывает четыре набора исправлений: XSA-524, XSA-525, XSA-529 и XSA-530.

Подбор токена по времени ответа

XAPI - стек управления XenServer, через который администраторы и хосты пула работают с гипервизором. Внутри пула хосты аутентифицируют запросы друг к другу с помощью Pool Secret, общего bearer-токена (маркер доступа, который предъявляется в запросе вместо логина и пароля). Если токен известен, атакующий общается с XAPI как доверенный хост.

В XSA-529 (CVE-2026-102705) ошибка нашлась в процедуре сравнения. Токен сверяется функцией, время работы которой зависит от сравниваемых данных. Ответ приходит быстрее или медленнее в зависимости от того, сколько первых символов совпало.

Разница измеряется в микросекундах. Но при большом числе запросов из неё складывается timing-атака (атака по времени, когда секрет восстанавливают по задержкам ответа). Атакующий перебирает токен посимвольно и в итоге получает его целиком.

Условия атаки

Эксплуатация сетевая: нужен доступ к сети управления XenServer. Учётная запись не требуется, права в самом XenServer тоже не нужны. Дополнительно атакующему нужно отправлять много запросов и достаточно точно измерять задержки, иначе сигнал теряется в сетевом шуме.

Уязвимость не связана с гостевой виртуальной машиной и не требует действий пользователя. Уязвимы все версии XAPI, обходных мер производитель не приводит.

Что исправляет патч

Исправленная XAPI сравнивает токен за постоянное время, поэтому задержка больше не зависит от совпадения символов. Дополнительно Citrix даёт команду для смены секрета.

Порядок важен. Сначала обновите все хосты пула, затем меняйте секрет командой "xe pool-secret-rotate". Если сменить секрет на хостах со старым кодом, уязвимая проверка останется в работе.

Слабости RBAC: от vm-admin до pool-admin

Второй набор проблем, XSA-530, касается RBAC (Role Based Access Control, ролевая модель доступа). В XAPI роли распределены по уровням: полностью полномочная pool-admin и ограниченные pool-operator, vm-power-admin, vm-admin. Ошибки в проверке полей и вызовов API позволяют выйти за рамки роли.

CVE-2026-102706: пользователь с ролью vm-admin через вызовы VM.create, VM.clone или VM.import записывает защищённые поля VM.other_config, VM.platform, VM.ha_restart_priority и VM.appliance.

CVE-2026-102707: тот же vm-admin через Network.create задаёт защищённые поля Network.other_config и Network.bridge.

CVE-2026-102708: роль vm-power-admin через PUT /messages с поддельным телом сообщения заставляет dom0 (служебный домен гипервизора) создать символическую ссылку или каталог от имени root.

CVE-2026-119779: любая аутентифицированная роль, включая read-only, может принудительно завершить произвольные задачи, передав чужой task_id.

CVE-2026-119780: pool-operator через поддельный repository_proxy_url внедряет произвольные директивы .repo для yum/dnf. Это создаёт путь к обходу проверки GPG-подписи репозитория.

Суммарный результат - повышение прав до pool-admin. Уязвимы все версии XAPI, но ошибка проявляется только там, где RBAC включён и пользователям выданы неполномочные роли.

Затронутые версии

Проблемы затрагивают XenServer 8.4 и XenServer 9. Citrix выложила исправления в оба канала обновлений, Early Access и Normal, поэтому подойдёт любой из них: важно поставить последнюю сборку.

Если обновиться нельзя

Для XSA-529 обходных мер нет, производитель прямо указывает на их отсутствие. Единственный вариант - обновление.

Для XSA-530 временная мера есть. Отключите всех субъектов RBAC с ролями read-only, vm-operator, vm-admin, vm-power-admin и pool-operator. Пул вернётся к модели, где полные права есть только у pool-admin, зато исчезает путь эскалации. Когда будете включать роли обратно, хосты должны быть уже обновлены.

AMD IOMMU и атаки на планировщик

В тот же бюллетень вошли два набора исправлений, не связанных с XAPI.

XSA-524 (CVE-2024-21963) - выход за границы таблицы устройств в AMD IOMMU, блоке управления доступом устройств к памяти. Размер и позицию Device Table выбирает ОС или гипервизор. На части систем AMD IOMMU читает за пределами этого размера и принимает прочитанное за корректные данные конфигурации. Если домен получает контроль над настройкой IOMMU для устройства, он может менять произвольную память хоста и поднять права до уровня Xen. Уязвимыми считаются только отдельные системы на AMD.

XSA-525 (CVE-2024-36350, CVE-2024-36357, CVE-2026-0004) - продолжение истории Transient Scheduler Attacks на процессорах AMD. Производитель исправил прежнее заявление: процессоры Zen5 уязвимы к TSA-SQ и TSA-L1, это отражено в AMD-SB-7073. Кроме того, раскрыт новый вариант TSA-Fill, он описан в AMD-SB-3031 под CVE-2026-0004. Атакующий может получить данные других контекстов, включая данные других гостевых машин. Обходных мер на уровне самого Xen нет: AMD выпускает микрокод, а виртуальные машины нужно перезагрузить, а не просто перенести, чтобы они подхватили изменение статуса.

Что сделать в первую очередь

Обновите все хосты пула до последней сборки XenServer 8.4 или 9, затем смените Pool Secret командой "xe pool-secret-rotate". Проверьте список субъектов RBAC: если в нём есть read-only, vm-operator, vm-admin, vm-power-admin или pool-operator, права этих учётных записей стоит пересмотреть. Отдельно запланируйте микрокод AMD и перезагрузку гостей на Zen5.