Я пытаюсь получить соответствие 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#Компенсация%20Элементов управлениядля определения компенсирующего контроля. Среди прочего "Компенсирующий контроль должен:…быть «выше и за пределами» других требований PCI DSS (а не просто соответствовать другим требованиям PCI DSS)", и отключение 'open_basedir' на самом деле не выходит за рамки, основная проблема должна быть действительно решена здесь. Опять же, требования, перечисленные в отчете сканирования, заключаются в обновлении системы или использовании упомянутых компенсирующих элементов управления (отключение open_basedir было бы недостаточным в этом случае).
При обнаружении любых проблем в системе, подпадающей под действие PCI DSS, необходимо устранить все проблемы, не соответствующие PCI (то есть любые системы, участвующие в хранении, обработке и/или передаче данных держателей кредитных карт, а также любые системы, напрямую подключенные к сети, участвующей в таких процессах, в которой не реализована надлежащая сегментация сети).
Ознакомьтесь с отчетом о сканировании и следуйте рекомендациям, приведенным в столбце «Исправление», а затем выполните еще одно сканирование после устранения уязвимости, чтобы удалить обнаруженные данные из следующего отчета о сканировании.
Если уязвимость продолжает обнаруживаться после этого момента и/или если вы уже выполнили это, то, пожалуйста, смело оспаривайте эту уязвимость повторно и объясните, какие действия были выполнены для устранения обнаруженного недостатка.
решение1
Кажется подозрительным, что 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настроенного, вся уязвимость совершенно неактуальна — никаких других изменений, обеспечивающих какие-либо дополнительные преимущества безопасности, сделано не было.