Ubuntu PCI-DSS Совместимость Проблема
Я пытаюсь получить соответствие 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 для определения компенсирующего элемента управления. Среди прочего "Компенсирующие средства управления должны:… быть" выше и выше "других требований 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 После настройки вся уязвимость совершенно не имеет значения - никаких других изменений не было сделано, чтобы обеспечить какие-либо дополнительные преимущества безопасности.