El truncamiento de ruta no funciona en PHP mientras se explota LFI

Question

El truncamiento de ruta no funciona en PHP mientras se explota LFI

#1 de Moshe Katz (1 votos)

1

Por lo que entiendo en PHP '/ etc / passwd /' o '/etc/passwd/./././' debe tratarse de la misma manera que '/ etc / passwd'

Estoy usando PHP 5.4 y esto no parece ser cierto:

php -r "include ('/ etc / passwd');"

funciona bien pero

php -r "include ('/ etc / passwd /');"

Advertencia: include (/ etc / passwd /): no se pudo abrir la transmisión: no existe tal archivo o   Directorio en el código de línea de comando en la línea 1

Advertencia: include (): error al abrir '/ etc / passwd /' para inclusión   (include_path = '.:') en el código de línea de comando en la línea 1

Lo mismo es cierto para:

php -r "include ('/ etc /./././ passwd');"

funciona!

php -r "include ('/ etc /./././ passwd /');"

Advertencia: incluya (/ etc /./././ passwd /): no se pudo abrir la transmisión: no existe   archivo o directorio en el código de línea de comando en la línea 1

Advertencia: include (): Error al abrir '/etc/./././passwd/' para inclusión   (include_path = '.:') en el código de línea de comando en la línea 1

no funciona!

¿Alguien puede hacerme saber si estoy haciendo algo mal o si se solucionó el problema de truncamiento de ruta?

web-application php

pregunta DimDim 25.05.2014 - 17:04

fuente

1 respuesta

Lea otras preguntas en las etiquetas web-application php

honeypot simple de Windows 7: ¿es seguro? Se negó el acceso periódico de retransmisión de Postfix

score 1 · Accepted Answer

El hallazgo de

"Realpath" se rehizo por completo en este compromiso el 12 de agosto de 2008, de alguna manera que ya no es vulnerable al ataque de truncamiento de ruta. Estos cambios se lanzaron en PHP 5.3.0, por lo que ninguna versión más reciente será vulnerable (a menos que se haya reintroducido el error, lo que no parece haber ocurrido).

Como nota aparte, no hay indicios de que alguien haya notificado a los desarrolladores de PHP sobre este ataque o que la solución para este ataque fue deliberada; en realidad, parece que se solucionó como un subproducto de corregir otro error.

Además, cuando se usa con NGINX y FastCGI, PHP sigue siendo vulnerable a un ataque similar en el que el intérprete de PHP lo hará procese una solicitud desde el servidor web, incluso si el nombre del archivo tiene elementos adicionales al final. Sin embargo, el comportamiento que permite este ataque es por diseño tanto en NGINX como en PHP, por lo que la única forma de protegerse es usar una de las cinco soluciones enumeradas.