В OpenStack Aodh до версии 22.0.1 API списка сигналов обходит область действия проекта, когда для параметра запроса all_projects установлено значение false. API проверяет наличие ключа all_projects, а не его значения; истинное значение применяет политику только администратора, но ложное значение удаляет ключ и пропускает ветвь, которая обычно ограничивает результаты проектом вызывающего объекта. Пользователь, не являющийся администратором, с ролью читателя может составлять список сигналов тревоги из всех проектов, предоставляя действия по сигналам тревоги, содержащие URL-адреса доверенных веб-перехватчиков, конечные точки тепловых сигналов, идентификаторы проектов и идентификаторы пользователей.
Этот параметр также можно комбинировать с внешним идентификатором проекта, чтобы настроить сигналы тревоги конкретного проекта. Связанная с этим проблема заключается в том, что OpenStack Watcher не применяет авторизацию к конечной точке триггера веб-перехватчика. Любой прошедший проверку подлинности пользователь, который узнает URL-адрес веб-перехватчика аудита, например, из этих утекших метаданных тревоги Aodh, может начать аудит EVENT и связанный с ним план действий независимо от своего собственного проекта или роли.
Конечная точка веб-перехватчика не применяла политику с момента ее появления в выпуске Ussuri (Watcher 4.0.0).
Показать оригинальное описание (EN)
In OpenStack Aodh before 22.0.1, the alarm list API bypasses project scoping when the all_projects query parameter is set to false. The API checks for the presence of the all_projects key rather than its value; a true value enforces the administrator-only policy, but a false value removes the key and skips the branch that normally restricts results to the caller's project. A non-admin user with the reader role can list alarms from all projects, exposing alarm actions containing trust webhook URLs, Heat signal endpoints, project IDs, and user IDs. The parameter can also be combined with a foreign project_id to target a specific project's alarms. A related concern is that OpenStack Watcher does not apply authorization to its webhook trigger endpoint. Any authenticated user who learns an audit's webhook URL, for example from this leaked Aodh alarm metadata, can start an EVENT audit and its associated action plan regardless of their own project or role. The webhook endpoint has lacked policy enforcement since its introduction in the Ussuri release (Watcher 4.0.0).
Характеристики атаки
Последствия
Строка CVSS v4.0