CVE-2011-1092 о соответствии Centos / PCI DSS
Сканирование безопасности сайта клиента выявило тот факт, что, поскольку они работали с PHP 5.3.3, они были уязвимы для CVE-2011-1092 (исправлено в 5.3.6 и выше).
Обычно я бы сказал, что бэкпортинг справился бы с этим, поскольку их PHP был перенесен в течение многих лет в 5.3.27, но в журнале изменений нет указаний на то, что этот конкретный CVE был адресован.
Просмотр https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-1092 и https://access.redhat.com/security/cve/CVE-2011-1092 однозначно указывает на то, что эта проблема не Эта проблема была рассмотрена в версии PHP, поставляемой с RHEL и Centos, потому что RHEL не считает, что это проблема безопасности.
Это ставит клиента перед дилеммой - его компания, занимающаяся сканером соответствия PCI DSS (Trustwave), не примет заявление RHEL о том, что "это не проблема безопасности", сказав: "Посещение [страница RHEL, ссылка на которую приведена выше], показывает, что RedHat имеет CVE-2011-1092 не рассматривается. Поскольку этот вывод влияет на соответствие стандарту PCI DSS, необходимо подтвердить, что он был рассмотрен каким-либо образом ".
У кого-нибудь есть предложения, как поступить? Можно ли решить проблему напрямую, исправив файлы каким-либо образом?
Спасибо заранее за любые предложения.
2 ответа
Именно так работает индустрия PCI-DSS - обученные обезьяны запускают программное обеспечение для автоматического сканирования приложений, а затем прыгают вверх и вниз, если он становится красным. Попытка рассуждать с обезьянами не выполняет никакой полезной функции, поскольку они понимают только красный и зеленый. Не поймите меня неправильно - парни, написавшие код в большинстве этих инструментов, очень умны, но они не те люди, с которыми вам приходится иметь дело. И, к сожалению, обезьяны получили много энергии. Существование проблемы не означает, что проблема может быть использована.
Справедливости ради по отношению к обезьянам, NIST оценил риск как "высокий". Но я согласен с Redhat - единственный способ использовать это - это кто-то, имеющий доступ к php-коду или если вы передаете введенные пользователем значения непосредственно в функции низкого уровня.
Если бы я был на вашем месте, то первым делом я бы проверил, использует ли код разделяемую память вообще - и если нет, то добавил бы соответствующую функцию в настройки disable_functions в php.ini. Хотя доказать, что ошибка не может быть использована злоумышленником с включенной функцией и ее использование в коде, сложно, можно доказать, что эту ошибку нельзя использовать, если функция недоступна. Будет ли это успокоить обезьян - это отдельная история, конечно.
Уязвимость влияет только на функцию shmop_read(), У вас есть возможность отключить функции в php.ini; если вы делаете это, и никаких ошибок не выдается, ваш код не использует и не может использовать эту функцию, поэтому вы в безопасности.