Estou tentando obter conformidade com PCI e a empresa de verificação de PCI está sinalizando nosso Ubuntu 12.04 PHP 5.3.10-1ubuntu3.9 para CVE-2013-1635. De acordo comhttp://people.canonical.com/~ubuntu-security/cve/2013/CVE-2013-1635.htmla resposta do Ubuntu é "Não oferecemos suporte ao usuário open_basedir" e todas as versões foram marcadas como ignoradas.
Não sei o que fazer aqui. Apontei para minha empresa de digitalização esse mesmo URL, mas eles não aceitam isso como resposta.
O que devo fazer?
Atualizar
Não utilizo esta funcionalidade e a diretiva open_basedir está desabilitada no php.ini. No entanto, eles não consideram esta uma solução adequada.
Aqui está a resposta deles à negação da minha disputa:
Negamos esta disputa com base nas informações fornecidas sobre como esta conclusão foi abordada. Descobriu-se que a versão do PHP atualmente em execução neste sistema não limpa adequadamente as entradas fornecidas pelo usuário. Apesar do 'open_basedir' estar desabilitado neste sistema, um invasor pode explorar esse problema e gravar arquivos WSDL dentro do contexto do aplicativo afetado. Além disso, descobriu-se que outros ataques também são possíveis. Como resultado, a diretiva 'soap.wsdl_cache_dir' define o nome do diretório onde a extensão SOAP colocará os arquivos de cache. Desabilitar 'open_basedir' não 1) removeu arquivos de cache que já existem e/ou 2) cessou a possibilidade de novos arquivos de cache serem colocados em um diretório arbitrário.
Por favor revisehttps://www.pcisecuritystandards.org/security_standards/glossary.php#Compensating%20Controlspara a definição de um controle compensatório. Entre outras coisas, "Os controles de compensação devem:… Estar “acima e além” de outros requisitos do PCI DSS (não simplesmente em conformidade com outros requisitos do PCI DSS)", e desabilitar 'open_basedir' não vai realmente além, o problema subjacente deveria realmente ser abordado aqui. Novamente, os requisitos listados no relatório de verificação são atualizar o sistema ou utilizar os controles de compensação mencionados (o que desabilitar open_basedir não seria suficiente neste caso).
Quaisquer problemas detectados em um sistema que esteja no escopo de conformidade com o PCI DSS precisariam ter todos os problemas não compatíveis com PCI corrigidos (que é qualquer sistema envolvido no armazenamento, processamento e/ou transmissão de dados do titular do cartão de crédito e qualquer sistema diretamente conectado a uma rede envolvida em tais processos que não possui segmentação de rede adequada).
Revise o relatório de verificação e siga as sugestões encontradas na coluna “Remediação” e, em seguida, execute outra verificação quando a vulnerabilidade for corrigida para limpar a descoberta do seu próximo relatório de verificação.
Se a vulnerabilidade continuar a ser detectada após este ponto e/ou se você já tiver feito isso, sinta-se à vontade para contestar novamente esta vulnerabilidade e explicar o que foi feito para resolver a descoberta.
Responder1
Parece suspeito que o Ubuntu "não suporta" uma diretiva de configuração padrão do PHP, já que eles já corrigiram bugs antes (por exemplo).
Editar: Parece que o Debian e o Red Hat têm a mesma política, na verdade - "não apoiar" é uma palavra ruim, mas todas essas distros são da opinião que falhas em um mecanismo de segurança inerentemente falho não são uma preocupação.
No entanto, isso provavelmente é irrelevante. Verifique php.inise há open_basedir- se não estiver lá, você não será afetado por esse problema de segurança, pois o bug é um desvio das restrições de segurança que open_basedirele fornece.
Se o seu auditor for especialmente ruim nisso, entretanto, seu melhor curso de ação pode ser simplesmente parar de mostrar a eles qual versão do PHP você está usando - a verificação de string de versão é uma maneira terrível de fazer avaliação de vulnerabilidade, de qualquer maneira. Se for um servidor web Apache mostrando suas strings de versão, forneça ServerSignature Offe ServerTokens Prod.
Edite com notas na resposta que eles lhe enviaram...
Descobriu-se que a versão do PHP atualmente em execução neste sistema não limpa adequadamente as entradas fornecidas pelo usuário.
Este bug não tem nada a ver com a higienização de entrada, é uma falha em uma mecânica de sandbox.
Apesar do 'open_basedir' estar desabilitado neste sistema, um invasor pode explorar esse problema e gravar arquivos WSDL dentro do contexto do aplicativo afetado.
Não sou de forma alguma um especialista nos aspectos internos do PHP, mas isso parece uma interpretação errada da vulnerabilidade. Pelo que posso dizer sobre esse bug, o problema é que um invasor pode usar a mecânica de cache WSDL para carregar um WSDL de um local de diretório fora da open_basedirraiz (mas provavelmente ainda dentro de soap.wsdl_cache_dir, cujo padrão é /tmp).
Para que isso tenha alguma importância, você precisaria ter arquivos que pudessem realmente ser direcionados dessa maneira e um método de acesso para acionar o armazenamento em cache (travessia de diretório em seu servidor web, talvez?)
De qualquer forma, acionar a criação de um WSDL em cache com base no conteúdo já existente no sistema é muito diferente de gravar arquivos em sua aplicação web.
Como resultado, a diretiva 'soap.wsdl_cache_dir' define o nome do diretório onde a extensão SOAP colocará os arquivos de cache. Desabilitar 'open_basedir' não 1) removeu arquivos de cache que já existem e/ou 2) cessou a possibilidade de novos arquivos de cache serem colocados em um diretório arbitrário.
Embora o CVE diga "diretório arbitrário", o que parece realmente significar é "o diretório de cache WSDL configurado". Esta vulnerabilidade seria muito mais séria se incluísse um componente de passagem de diretório. Na realidade, tudo o que mudou foi adicionar validação para garantir que o diretório de cache esteja dentro do arquivo open_basedir. Veraqui.
desabilitar 'open_basedir' não vai muito além, o problema subjacente deve realmente ser abordado aqui
Isso não faz sentido. Este é um bug em que o diretório de cache WSDL não validava corretamente que estava dentro do arquivo open_basedir. Se você não tiver open_basedirconfigurado, toda a vulnerabilidade será completamente irrelevante - nenhuma outra alteração foi feita para fornecer qualquer benefício adicional de segurança.