2

From what I understand in PHP '/etc/passwd/' or '/etc/passwd/./././' should be treated just the same as '/etc/passwd'

I am using PHP 5.4 and this does not seem to be true:

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

works fine but

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

Warning: include(/etc/passwd/): failed to open stream: No such file or directory in Command line code on line 1

Warning: include(): Failed opening '/etc/passwd/' for inclusion (include_path='.:') in Command line code on line 1

The same is true for :

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

works!

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

Warning: include(/etc/./././passwd/): failed to open stream: No such file or directory in Command line code on line 1

Warning: include(): Failed opening '/etc/./././passwd/' for inclusion (include_path='.:') in Command line code on line 1

does not work!

Can someone please let me know if I am doing anything wrong or is the path truncation issue fixed?

DimDim
  • 23
  • 1
  • 3
  • Unix systems assume a path ending with a slash as a directory and `/etc/passwd` is certainly not a directory. – Gumbo May 25 '14 at 15:55
  • @Gumbo the whole point of this vulnerability was that PHP would include the file even though the slash was there! – Moshe Katz May 28 '14 at 01:53

1 Answers1

2

"Realpath" finding was completely redone in this commit on August 12, 2008, in a way that is no longer vulnerable to the path truncation attack. These changes were released in PHP 5.3.0, so no version newer than that will be vulnerable (unless the bug was reintroduced, which does not seem to have happened).

As an aside, there is no indication that anyone ever notified the PHP developers of this attack or that the fix for this attack was deliberate - it actually seems that it was fixed as a byproduct of fixing another bug.

Additionally, when used with NGINX and FastCGI, PHP is still vulnerable to a similar attack in which the PHP interpreter will process a request from the webserver even if the filename has extra stuff on the end. However, the behavior that allows this attack is by design in both NGINX and PHP, so the only way to protect from it is to use one of the five listed workarounds.

Moshe Katz
  • 1,331
  • 1
  • 11
  • 17