Parece suspeito que o Ubuntu "não suporta" uma diretiva de configuração PHP, já que eles corrigiram erros antes ( por exemplo ).
Editar : Parece que o Debian e a Red Hat têm a mesma política, na verdade - "não suporta" é um termo ruim, mas todas essas distribuições são da opinião de que falhas em uma falha inerente mecanismo de segurança não é uma preocupação.
No entanto, isso é provavelmente irrelevante. Verifique seu php.ini para open_basedir - se não estiver lá, você não será afetado por esse problema de segurança, já que o bug é um desvio das restrições de segurança que o open_basedir fornece.
Se o seu auditor é especialmente ruim nisso, seu melhor curso de ação pode ser simplesmente parar de mostrar a versão do PHP em que você está - a verificação de string de versão é uma maneira terrível de fazer a avaliação de vulnerabilidade. Se for um servidor da web Apache mostrando suas sequências de versão, atribua ServerSignature Off e ServerTokens Prod .
Edite com anotações sobre a resposta que eles enviaram a você ...
The version of PHP that is currently running on this system has been found to not properly sanitize user-supplied input.
Esse bug não tem nada a ver com a limpeza de entrada, é uma falha em uma mecânica de sandboxing.
Despite the fact that 'open_basedir' is disabled on this system, an attacker can exploit this issue and write wsdl files within the context of the affected application.
Eu não sou de forma alguma um especialista nos aspectos internos do PHP, mas isso parece ser uma má interpretação séria da vulnerabilidade. Pelo que posso dizer sobre esse bug, o problema é que um invasor pode usar a Mecanismo de Armazenamento em Cache do WSDL para carregar um WSDL de um local de diretório fora da raiz open_basedir (mas provavelmente ainda dentro do soap.wsdl_cache_dir , cujo padrão é /tmp ).
Para que isso importe, você precisa ter arquivos que possam ser segmentados dessa maneira e um método de acesso para ativá-lo em cache (travessia de diretório em seu servidor da Web, talvez?)
De qualquer forma, acionar a criação de um WSDL em cache com base no conteúdo que já está no sistema é muito diferente de gravar arquivos em seu aplicativo da Web.
As a result, the 'soap.wsdl_cache_dir' directive sets the directory name where the SOAP extension will place the cache files. Disabling 'open_basedir' has not 1) removed cache files that already exist and/or 2) ceased the possibility of new cache files from being placed into an arbitrary directory.
Enquanto o CVE diz "diretório arbitrário", o que parece realmente significar é "o diretório de cache do WSDL configurado". Esta vulnerabilidade seria muito mais séria se incluísse um componente de travessia de diretório. Na realidade, tudo o que foi alterado foi adicionar validação para garantir que o diretório de cache esteja dentro do open_basedir . Veja aqui .
disabling 'open_basedir' does not really go above and beyond, the underlying issue should really be addressed here
Isso é um absurdo. Este é um bug em que o diretório de cache do WSDL não validou corretamente que estava dentro de open_basedir . Se você não tiver um open_basedir configurado, a vulnerabilidade inteira é completamente irrelevante - nenhuma outra alteração foi feita para fornecer qualquer benefício de segurança adicional.