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.

  • Factores de performance y security de enlaces simbólicos
  • configuration de un host virtual mod_proxy básico
  • netstat y el recuento de conexiones ip_conntrack difieren por order de magnitud. ¿Por qué?
  • Alto uso de la CPU con wineconsole ejecutándose en segundo plano
  • Aumento repentino en el uso de la CPU y el time de respuesta del server
  • Ubuntu: reinstalar la biblioteca jpeg
  • Registro local y remoto con rsyslogd
  • Problemas de networking de Ubuntu 8.04 Server (x64) en vSphere 4
  • Fail2Ban intenta prohibir la propiedad intelectual pero IP no se prohibe - la cadena iptables existe pero no funciona
  • Software RAID 1 no se extiende en dos nuevas unidades adicionales
  • ¿Cómo apagar Ubuntu automáticamente minutos X después de iniciar?
  • Eucalyptus / ubuntu-server-11.04 - la instancia está en ejecución pero no puede acceder a ella
  • Nuevo server: todos los files de logging archivados después de la primera noche
  • El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.