I was asked by someone about the exploit from http://securityreason.com/achievement_exploitalert/14. Why they could not delete the created symbolic links?
The exploit explanation is in http://securityreason.com/achievement_securityalert/70 (if you have a problem to access it, here is the backup http://seclists.org/fulldisclosure/2009/Nov/165).
This exploit just creates a symbolic link to a file outside the open_basedir with a neat trick, then using web server to access it (not invoking PHP interpreter). In my opinion, this is not PHP vulnerability. This is a feature (you still can do it with latest PHP). If we try to access the symbolic link with PHP functions (such as readfile(), file_get_contents()), we will get the error message related to open_basedir. Also we cannot delete/modify the symbolic links with unlink() PHP functions because of open_basedir restriction (answer the above question).
I think the easier way to abuse this feature is creating the symbolic link to root directory. No exploit from me. It's so easy to write :).
The workaround for this problem is adding symlink() using "disable_functions" feature to disable function or disabling following symbolic link in web server (FollowSymLinks in apache).
Update: I overlooked the method to delete the symbolic link. We just need to do the reverse by removing directory and recreating the tmplink. Here is the PHP code to delete the symbolic link that is created with kakao.php from the advisory.
<?php rmdir("tmplink"); symlink("abc/abc/abc/abc","tmplink"); unlink("exploit"); unlink("tmplink");
Update:If you install Suhosin patch, you are safe from this problem by default. See http://www.hardened-php.net/suhosin/configuration.html#suhosin.executor.allow_symlink for more information.
Su Koi
ReplyDelete