PCI 규격을 얻으려고 하는데 PCI 스캐닝 회사에서 CVE-2013-1635에 대해 Ubuntu 12.04 PHP 5.3.10-1ubuntu3.9를 표시하고 있습니다. 에 따르면http://people.canonical.com/~ubuntu-security/cve/2013/CVE-2013-1635.htmlUbuntu 응답은 "우리는 open_basedir 사용자를 지원하지 않습니다"이며 모든 버전은 무시된 것으로 표시되었습니다.
여기서 무엇을 해야할지 모르겠습니다. 내 스캐닝 회사에 이와 동일한 URL을 지정했지만 해당 회사에서는 이를 받아들이지 않고 답변합니다.
어떻게 해야 하나요?
업데이트
저는 이 기능을 사용하지 않으며 php.ini에서는 open_basedir 지시문이 비활성화되어 있습니다. 그러나 그들은 이것이 적절한 해결책이라고 생각하지 않습니다.
내 분쟁을 거부한 것에 대한 그들의 반응은 다음과 같습니다.
우리는 이 조사 결과가 어떻게 해결되었는지에 관해 제공된 정보를 바탕으로 이 분쟁을 부인했습니다. 현재 이 시스템에서 실행 중인 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 비준수 문제를 모두 해결해야 합니다(신용 카드 소지자 데이터의 저장, 처리 및/또는 전송과 관련된 시스템 및 모든 시스템을 직접적으로 포함). 적절한 네트워크 분할이 이루어지지 않은 프로세스와 관련된 네트워크에 연결되어 있음).
스캔 보고서를 검토하고 "수정" 열 아래에 있는 제안 사항을 따른 다음, 취약점이 수정되면 또 다른 스캔을 수행하여 다음 스캔 보고서에서 결과를 삭제하세요.
이 시점 이후에도 취약점이 계속 감지되거나 이미 이 작업을 수행한 경우 이 취약점에 대해 다시 이의를 제기하고 결과를 해결하기 위해 수행된 작업을 설명하십시오.
답변1
우분투는 이전에 버그를 수정했기 때문에 기본 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전체 취약점은 전혀 관련이 없습니다. 추가 보안 이점을 제공하기 위한 다른 변경 사항은 전혀 없습니다.