Estoy tratando de cumplir con PCI y la compañía de escaneo de PCI está marcando nuestro Ubuntu 12.04 PHP 5.3.10-1ubuntu3.9 para CVE-2013-1635. De acuerdo ahttp://people.canonical.com/~ubuntu-security/cve/2013/CVE-2013-1635.htmlla respuesta de Ubuntu es "No admitimos al usuario de open_basedir" y todas las versiones se han marcado como ignoradas.
No sé qué hacer aquí. Le he indicado a mi empresa de escaneo esta misma URL, pero no la aceptan y responden.
¿Qué tengo que hacer?
Actualizar
No uso esta funcionalidad y la directiva open_basedir está deshabilitada en php.ini. Sin embargo, no consideran que ésta sea una solución adecuada.
Aquí está su respuesta a su negación de mi disputa:
Hemos negado esta disputa basándonos en la información proporcionada sobre cómo se ha abordado este hallazgo. Se ha descubierto que la versión de PHP que se ejecuta actualmente en este sistema no desinfecta adecuadamente la entrada proporcionada por el usuario. A pesar de que 'open_basedir' está deshabilitado en este sistema, un atacante puede aprovechar este problema y escribir archivos wsdl dentro del contexto de la aplicación afectada. Además, se ha descubierto que también son posibles otros ataques. Como resultado, la directiva 'soap.wsdl_cache_dir' establece el nombre del directorio donde la extensión SOAP colocará los archivos de caché. La desactivación de 'open_basedir' no 1) eliminó los archivos de caché que ya existen y/o 2) eliminó la posibilidad de que se coloquen nuevos archivos de caché en un directorio arbitrario.
Por favor revisehttps://www.pcisecuritystandards.org/security_standards/glossary.php#Compensating%20Controlspara la definición de un control compensatorio. Entre otras cosas, "los controles compensatorios deben:...estar "por encima y más allá" de otros requisitos de PCI DSS (no simplemente cumplir con otros requisitos de PCI DSS)", y deshabilitar 'open_basedir' realmente no va más allá, el problema subyacente realmente debería abordarse aquí. Nuevamente, los requisitos enumerados en el informe de escaneo son actualizar el sistema o utilizar los controles de compensación mencionados (los cuales, deshabilitar open_basedir no sería suficiente en este caso).
Cualquier problema detectado en un sistema que esté dentro del alcance del cumplimiento de PCI DSS deberá solucionar todos los problemas que no cumplan con PCI (es decir, cualquier sistema involucrado en el almacenamiento, procesamiento y/o transmisión de datos de titulares de tarjetas de crédito y cualquier sistema directamente conectado a una red involucrada en dichos procesos que no cuenta con una segmentación de red adecuada).
Revise el informe de análisis y siga las sugerencias que se encuentran debajo de la columna "Remediación" y luego realice otro análisis cuando se haya solucionado la vulnerabilidad para borrar el hallazgo de su próximo informe de análisis.
Si la vulnerabilidad continúa detectándose después de este punto y/o si ya lo ha realizado, no dude en volver a disputar esta vulnerabilidad y explicar qué se realizó para abordar el hallazgo.
Respuesta1
Parece sospechoso que Ubuntu "no admite" una directiva de configuración PHP estándar, ya que han solucionado errores antes (por ejemplo).
Editar: Parece que Debian y Red Hat tienen la misma política, en realidad: "no dar soporte" es una mala redacción, pero todas estas distribuciones opinan que las fallas en un mecanismo de seguridad inherentemente defectuoso no son una preocupación.
Sin embargo, eso probablemente sea irrelevante. Verifique si no está allí, entonces este problema de seguridad no lo afecta en absoluto, ya que el error es una elusión de las restricciones de seguridad que php.iniproporciona .open_basediropen_basedir
Sin embargo, si su auditor es especialmente malo en esto, su mejor curso de acción podría ser simplemente dejar de mostrarles en qué versión de PHP está; de todos modos, la verificación de cadenas de versión es una forma terrible de realizar una evaluación de vulnerabilidad. Si es un servidor web Apache que muestra sus cadenas de versión, dale ServerSignature Offy ServerTokens Prod.
Edite con notas sobre la respuesta que le enviaron...
Se ha descubierto que la versión de PHP que se ejecuta actualmente en este sistema no desinfecta adecuadamente la entrada proporcionada por el usuario.
Este error no tiene nada que ver con la desinfección de la entrada, es una falla en la mecánica del sandboxing.
A pesar de que 'open_basedir' está deshabilitado en este sistema, un atacante puede aprovechar este problema y escribir archivos wsdl dentro del contexto de la aplicación afectada.
De ninguna manera soy un experto en los aspectos internos de PHP, pero eso parece una grave mala interpretación de la vulnerabilidad. Por lo que puedo decir sobre este error, el problema es que un atacante puede usar la mecánica de almacenamiento en caché de WSDL para cargar un WSDL desde una ubicación de directorio fuera de la open_basedirraíz (pero probablemente todavía dentro de soap.wsdl_cache_dir, cuyo valor predeterminado es /tmp).
Para que esto importe, tendría que tener archivos a los que realmente se pueda acceder de esta manera y un método de acceso para activar su almacenamiento en caché (¿recorrido de directorio en su servidor web, tal vez?)
En cualquier caso, desencadenar la creación de un WSDL en caché basado en el contenido que ya está en el sistema es muy diferente a escribir archivos en su aplicación web.
Como resultado, la directiva 'soap.wsdl_cache_dir' establece el nombre del directorio donde la extensión SOAP colocará los archivos de caché. La desactivación de 'open_basedir' no 1) eliminó los archivos de caché que ya existen y/o 2) eliminó la posibilidad de que se coloquen nuevos archivos de caché en un directorio arbitrario.
Si bien el CVE dice "directorio arbitrario", lo que realmente parece significar es "el directorio de caché WSDL configurado". Esta vulnerabilidad sería mucho más grave si incluyera un componente de recorrido de directorio. En realidad, todo lo que se cambió fue agregar validación para asegurarse de que el directorio de caché esté dentro del archivo open_basedir. Veraquí.
Deshabilitar 'open_basedir' realmente no va más allá, el problema subyacente realmente debería abordarse aquí
Eso es una tontería. Este es un error en el que el directorio de caché WSDL no validó correctamente que estaba dentro del archivo open_basedir. Si no tiene una open_basedirconfiguración configurada, toda la vulnerabilidad es completamente irrelevante: no se realizaron otros cambios para proporcionar ningún beneficio de seguridad adicional.