Я пытаюсь добиться совместимости с PCI, и компания, занимающаяся сканированием PCI, отмечает наш Ubuntu 12.04 PHP 5.3.10-1ubuntu3.9 для CVE-2013-1635. В соответствии с http://people.canonical.com/~ubuntu-security/cve/2013/CVE-2013-1635.html ответ Ubuntu: «Мы не поддерживаем пользователя open_basedir», и все версии были отмечены как проигнорированные.
Я не понимаю, что здесь делать. Я указал своей сканирующей компании на тот же URL-адрес, но они не принимают это как ответ.
Что я должен делать?
Обновить
Я не использую эту функцию, а директива open_basedir отключена в php.ini. Однако они не считают это правильным решением.
Вот их ответ на отрицание моего спора:
Мы отклонили этот спор на основании предоставленной информации о том, как был решен этот вывод. Было обнаружено, что версия PHP, которая в настоящее время работает в этой системе, не очищает вводимые пользователем данные должным образом. Несмотря на то, что open_basedir отключен в этой системе, злоумышленник может воспользоваться этой проблемой и записать файлы wsdl в контексте затронутого приложения. Также было обнаружено, что возможны и другие атаки. В результате директива 'soap.wsdl_cache_dir' устанавливает имя каталога, в котором расширение SOAP будет размещать файлы кеша. Отключение 'open_basedir' не 1) не удалило файлы кеша, которые уже существуют, и / или 2) исключило возможность помещения новых файлов кеша в произвольный каталог.
Пожалуйста, просмотрите https://www.pcisecuritystandards.org/security_standards/glossary.php#Compensating%20Controls для определения компенсирующего управления. Среди прочего, «Компенсационные меры должны:… быть« выше и выше »других требований PCI DSS (а не просто соответствовать другим требованиям PCI DSS)», и отключение open_basedir на самом деле не выходит за рамки, основная проблема действительно должна обращаться здесь. Опять же, требования, перечисленные в отчете о сканировании, состоят в том, чтобы обновить систему или использовать упомянутые компенсирующие элементы управления (которых в данном случае недостаточно для отключения open_basedir).
Для любых проблем, обнаруженных в системе, которая соответствует требованиям PCI DSS, необходимо будет устранить все проблемы, не соответствующие требованиям PCI (что является любой системой, участвующей в хранении, обработке и / или передаче данных держателя кредитной карты, а также любой системе напрямую подключен к сети, участвующей в таких процессах, в которой отсутствует надлежащая сегментация сети).
Просмотрите отчет о сканировании и следуйте предложениям, приведенным в столбце «Устранение», а затем выполните еще одно сканирование, когда уязвимость будет устранена, чтобы удалить результаты из следующего отчета о сканировании.
Если уязвимость продолжает обнаруживаться после этого момента и / или если вы уже выполнили это, пожалуйста, не стесняйтесь повторно оспорить эту уязвимость и объяснить, что было сделано для устранения обнаруженной уязвимости.
Кажется подозрительным, что Ubuntu "не поддерживает" стандартную директиву конфигурации PHP, поскольку они исправляли ошибки с ней раньше (например).
редактировать: Похоже, что у Debian и Red Hat одна и та же политика, на самом деле - «не поддерживать» - плохая формулировка, но все эти дистрибутивы придерживаются мнения, что недостатки в механизме безопасности по своей сути не являются проблемой.
Однако это, вероятно, не имеет значения. Проверьте свои php.ini для open_basedir - если его там нет, то эта проблема безопасности совершенно не влияет на вас, поскольку ошибка является обходом ограничений безопасности, которые open_basedir обеспечивает.
Однако, если ваш аудитор особенно плох в этом, вам лучше всего просто перестать показывать им, на какой версии PHP вы работаете - в любом случае проверка строки версии - это ужасный способ оценки уязвимости. Если это веб-сервер Apache, показывающий строки своей версии, дайте ему ServerSignature Off и ServerTokens Prod.
Отредактируйте с примечаниями к ответу, который они вам прислали ...
Было обнаружено, что версия PHP, которая в настоящее время работает в этой системе, не обрабатывает вводимые пользователем данные должным образом.
Эта ошибка не имеет ничего общего с дезинфекцией ввода, это недостаток механики песочницы.
Несмотря на то, что open_basedir отключен в этой системе, злоумышленник может воспользоваться этой проблемой и записать файлы wsdl в контексте затронутого приложения.
Я ни в коем случае не эксперт во внутреннем устройстве PHP, но это похоже на серьезное неверное истолкование уязвимости. Из того, что я могу сказать об этой ошибке, проблема в том, что злоумышленник может использовать механизм кэширования WSDL для загрузки WSDL из каталога за пределами open_basedir корень (но, вероятно, все еще в пределах soap.wsdl_cache_dir, который по умолчанию /tmp).
Чтобы это имело какое-то значение, вам понадобятся файлы, которые могут быть нацелены таким образом, и метод доступа, чтобы инициировать их кеширование (возможно, обход каталога на вашем веб-сервере?)
В любом случае запуск создания кэшированного WSDL на основе содержимого, уже находящегося в системе, сильно отличается от записи файлов в ваше веб-приложение.
В результате директива soap.wsdl_cache_dir устанавливает имя каталога, в котором расширение SOAP будет размещать файлы кеша. Отключение open_basedir не 1) не привело к удалению уже существующих файлов кеша и / или 2) исключило возможность размещения новых файлов кеша в произвольном каталоге.
Хотя CVE действительно говорит «произвольный каталог», на самом деле, похоже, это означает «настроенный каталог кэша WSDL». Эта уязвимость была бы гораздо более серьезной, если бы она включала компонент обхода каталогов. На самом деле все, что было изменено, - это добавление проверки, чтобы убедиться, что каталог кеша находится в пределах open_basedir. Видеть Вот.
отключение open_basedir на самом деле не выходит за рамки, основная проблема действительно должна быть решена здесь
Это чепуха. Это ошибка, из-за которой каталог кеша WSDL не проверял должным образом, что он находится в open_basedir. Если у вас нет open_basedir настроена, вся уязвимость полностью не имеет значения - никаких других изменений не было внесено для обеспечения каких-либо дополнительных преимуществ безопасности.