Ранее Puppet работал на модели, согласно которой узел с действующим сертификатом имел право на всю информацию в системе и что скомпрометиро…
Ранее Puppet работал на модели, согласно которой узел с действующим сертификатом имел право на всю информацию в системе и что скомпрометированный сертификат позволял получить доступ ко всему в инфраструктуре. Когда каталог узла возвращается к узлу `default`, каталог можно получить для другого узла, изменив факты для запуска Puppet. Эту проблему можно смягчить, установив `strict_hostname_checking = true` в `puppet.conf` на вашем мастере Puppet. Puppet 6.13.0 и 5.5.19 изменяют поведение по умолчанию для strict_hostname_checking с false на true. Пользователям Puppet Open Source и Puppet Enterprise, которые не обновляются, рекомендуется по-прежнему устанавливать strict_hostname_checking в true, чтобы обеспечить безопасное поведение. Затронутые версии программного обеспечения: Puppet 6.x до 6.13.0 Puppet Agent 6.x до 6.13.0 Puppet 5.5.x до 5.5.19 Puppet Agent 5.5.x до 5.5.19 Устранено в: Puppet 6.13.0 Puppet Agent 6.13.0 Puppet 5.5.19 Puppet Agent 5.5.19.
Продукт не проверяет или некорректно проверяет сертификат.
https://cwe.mitre.org/data/definitions/295.html →Открыть в коллекции CWE →Продукт взаимодействует с хостом, предоставляющим сертификат, однако не обеспечивает должной проверки фактической связи сертификата с этим хостом.
https://cwe.mitre.org/data/definitions/297.html →Открыть в коллекции CWE →Злоумышленник эксплуатирует слабость, возникающую вследствие применения хеш-алгоритма с низкой устойчивостью к коллизиям, для генерации запросов на подпись сертификата (CSR), содержащих блоки коллизий в разделах «подписываемых данных». Злоумышленник отправляет один CSR на подписание доверенному удостоверяющему центру, а затем использует подписанный блок для того, чтобы второй сертификат выглядел подписанным тем же удостоверяющим центром. Вследствие хеш-коллизии оба сертификата, будучи различными, дают одно и то же хеш-значение, и подписанный блок одинаково работает с обоими сертификатами. В итоге второй сертификат X.509 злоумышленника, который удостоверяющий центр никогда не видел, оказывается подписанным и верифицированным этим удостоверяющим центром.
https://capec.mitre.org/data/definitions/459.html →Открыть в коллекции CAPEC →Злоумышленник эксплуатирует криптографическую слабость в реализации алгоритма проверки подписи для генерации действительной подписи без знания ключа.
https://capec.mitre.org/data/definitions/475.html →Открыть в коллекции CAPEC →| Продукт | Вендор | Статус |
|---|---|---|
| ansible-collection-redhat-satellite | Отслеживается | |
| ansible-collection-redhat-satellite | Отслеживается | |
| ansible-runner | Отслеживается | |
| ansible-runner | Отслеживается | |
| ansiblerole-foreman_scap_client | Отслеживается | |
| ansiblerole-foreman_scap_client | Отслеживается | |
| ansiblerole-insights-client | Отслеживается | |
| ansiblerole-insights-client | Отслеживается | |
| ansiblerole-satellite-receptor-installer | Отслеживается | |
| ansiblerole-satellite-receptor-installer | Отслеживается | |
| candlepin | Отслеживается | |
| candlepin | Отслеживается | |
| createrepo_c | Отслеживается | |
| createrepo_c | Отслеживается | |
| foreman | Отслеживается | |
| foreman | Отслеживается | |
| foreman-bootloaders-redhat | Отслеживается | |
| foreman-bootloaders-redhat | Отслеживается | |
| foreman-discovery-image | Отслеживается | |
| foreman-discovery-image | Отслеживается |