Problema de cumplimiento de Ubuntu PCI-DSS

Estoy tratando de get PCI compatible y la empresa de escaneo PCI está marcando nuestro Ubuntu 12.04 PHP 5.3.10-1ubuntu3.9 para CVE-2013-1635. De acuerdo con http://people.canonical.com/~ubuntu-security/cve/2013/CVE-2013-1635.html la respuesta de Ubuntu es "No soportamos el usuario de open_basedir" y todas las versiones han sido marcadas como ignoradas .

Estoy en una pérdida para qué hacer aquí. He señalado mi empresa de escaneado a esta misma URL, pero no aceptan que como y respuesta.

¿Que debería hacer?

Actualizar

No utilizo esta funcionalidad y la directiva open_basedir está deshabilitada en php.ini. Sin embargo, no consideran esto una solución adecuada.

He aquí su respuesta a su negación de mi disputa:

Hemos rechazado esta disputa basándose en la información proporcionada sobre cómo se ha tratado este hallazgo. La versión de PHP que se está ejecutando actualmente en este sistema ha sido encontrada para no desinfectar adecuadamente la input suministrada por el usuario. A pesar de que 'open_basedir' está desactivado en este sistema, un atacante puede explotar este problema y escribir files wsdl dentro del context de la aplicación afectada. También, se ha encontrado que otros ataques son también posibles. Como resultado, la directiva 'soap.wsdl_cache_dir' establece el nombre del directory donde la extensión SOAP colocará los files de caching. La desactivación de 'open_basedir' no tiene 1) los files de caching que ya existen y / o 2) cesó la posibilidad de que los nuevos files de caching se coloquen en un directory arbitrario.

Revise https://www.pcisecuritystandards.org/security_standards/glossary.php#Compensating%20Controls para la definición de un control de compensación. Entre otras cosas, "los controles de compensación deben: … estar" por encima y más allá "de otros requisitos de PCI DSS (no simplemente en cumplimiento con otros requisitos de PCI DSS)", y la inhabilitación de "open_basedir" no va realmente más allá. se tratará aquí. Una vez más, los requisitos enumerados en el informe de exploración son actualizar el sistema o utilizar los controles de compensación mencionados (que, inhabilitar open_basedir no sería suficiente en este caso).

Cualquier problema detectado en un sistema que tenga scope para el cumplimiento de PCI DSS necesitaría remediarse todos los problemas no compatibles de PCI (que es cualquier sistema involucrado en el almacenamiento, procesamiento y / o transmisión de datos de titular de tarjeta de crédito y cualquier sistema directamente conectado a una networking implicada en tales processs que no tiene segmentación apropiada de la networking en el lugar).

Revise el informe de análisis y siga las sugerencias que se encuentran debajo de la columna "Remediación" y realice otra exploración cuando la vulnerabilidad se haya remediado para borrar el hallazgo del informe de análisis siguiente.

Si la vulnerabilidad sigue siendo detectada después de este punto y / o si ya lo ha hecho, por favor, no dude en volver a discutir esta vulnerabilidad y explique qué se realizó para solucionar el problema.

One Solution collect form web for “Problema de cumplimiento de Ubuntu PCI-DSS”

Parece sospechoso que Ubuntu "no soporta" una directiva de configuration de PHP de stock, ya que ha arreglado los errores antes ( por ejemplo ).

Editar : Parece que Debian y Red Hat tienen la misma política, en realidad – "no apoyo" es mala networkingacción, pero todas estas distros son de la opinión de que las fallas en un mecanismo de security inherentemente defectuoso no son una preocupación.

Por estas razones, los errores en las opciones "safe mode" y "open_basedir", o cualquier error en el intérprete de PHP o extensiones que permitan que los scripts pasen por alto estas opciones, no serán tratados como sensibles a la security.

Sin embargo, eso es probablemente irrelevante. Compruebe su php.ini para open_basedir – si no está allí, entonces no se open_basedir afectado por este problema de security, ya que el error es un bypass de las restricciones de security que proporciona open_basedir .

Si su auditor es especialmente malo en esto, sin embargo, su mejor curso de acción podría ser simplemente dejar de mostrarles qué versión de PHP estás – la verificación de la cadena de versión es una forma terrible de hacer la evaluación de la vulnerabilidad, de todos modos. Si se trata de un server web Apache que muestra sus cadenas de versión, dale ServerSignature Off y ServerTokens Prod .

Edita con notas sobre la respuesta que te enviaron …

La versión de PHP que se está ejecutando actualmente en este sistema ha sido encontrada para no desinfectar adecuadamente la input suministrada por el usuario.

Este error no tiene nada que ver con desinfectar la input, es una falla en un mecánico de sandboxing.

A pesar de que 'open_basedir' está desactivado en este sistema, un atacante puede explotar este problema y escribir files wsdl dentro del context de la aplicación afectada.

No soy de ninguna manera un experto en los internos de PHP, pero eso parece ser una mala interpretación de la vulnerabilidad. De lo que puedo contar sobre este error, el problema es que un atacante puede usar el mecanismo de almacenamiento en caching de WSDL para cargar un WSDL desde una location de directory fuera de la raíz open_basedir (pero probablemente aún dentro del soap.wsdl_cache_dir , que es por defecto a /tmp ) .

Para que esto tenga en count, tendría que tener files que realmente podrían ser object de esta manera y un método de acceso para activar que se almacena en caching (directory de recorrido en su server web, tal vez?)

En cualquier caso, desencadenar la creación de un WSDL en caching basado en el contenido que ya está en el sistema es muy diferente de escribir files en su aplicación web.

Como resultado, la directiva 'soap.wsdl_cache_dir' establece el nombre del directory donde la extensión SOAP colocará los files de caching. La desactivación de 'open_basedir' no tiene 1) los files de caching que ya existen y / o 2) cesó la posibilidad de que los nuevos files de caching se coloquen en un directory arbitrario.

Mientras que el CVE dice "directory arbitrario", lo que realmente significa es "el directory de caching WSDL configurado". Esta vulnerabilidad sería mucho más grave si incluía un componente de recorrido de directory. En realidad, todo lo que se cambió fue la adición de validation para asegurarse de que el directory de caching está dentro de la open_basedir . Vea aquí .

la inhabilitación de "open_basedir" no va realmente más allá, la cuestión subyacente realmente debe ser abordado aquí

Eso es una tontería. Se trata de un error en el que el directory de caching de WSDL no validó correctamente que estaba dentro de open_basedir . Si no tiene configurado un open_basedir , toda la vulnerabilidad es completamente irrelevante – no se realizaron otros cambios para proporcionar ningún beneficio de security adicional.

  • ¿Falló con la prueba de ab con nginx, dos trabajadores y 1024 conexiones?
  • ZFS en> disco de 2 TB en Ubuntu 12.04?
  • ssh en Ubuntu falla después de la primera vez: Rutas asimétricas, la connection SSH falla en establecer correctamente
  • Deshabilitar el inicio de session de contraseña para determinados usuarios de SSH
  • ¿Son las herramientas de gestión de configuration (títeres, Chef) capaces de mantener actualizados los packages instalados?
  • VPN en el server de ubuntu 14.04
  • No queda espacio en el dispositivo, pero hay espacio
  • mod_security regla demasiado estricta?
  • Shell Scripting - Cómo replace líneas
  • ¿Por qué la variable no está disponible?
  • Cómo configurar variables de entorno PHP en Ubuntu
  • Ubuntu y Teléfonos Avaya
  • ¿Por qué networkinghat parece ser tan popular en el mundo empresarial?
  • El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.