Requested PHP Security Patches

Friday, December 22. 2006

A few days ago one of our users requested that I look into some security features requested 2 years ago on bugs.php.net by Peter Brodersen. The first one is an addition to the session extension that stops attempts to access the session data of another user during SAFE MODE and the second one is a change in the behaviour of glob() to better obey SAFE MODE and open_basedir restrictions. In plain PHP glob() allows retrieving a list of all files on the server through the SAFE MODE or open_basedir error messages.

While I consider SAFE MODE and open_basedir broken solutions that should get replaced by proper UNIX file permissions I created two patches for both problems to make the users happy. The first problem is solved by appending the UID of the script to the session filename during safe_mode and the second one by performing silent safe_mode/open_basedir check for every single file. I did not bother commiting the patches into the PHP CVS because the bug was rejected several times as bogus.

glob_safe_mode_open_basedir_fix

session_safe_mode_postfix

Posted by Stefan Esser in PHP, Security at 23:51

Comments (7)

Link to this post

Comments

Display comments as (Linear | Threaded)

#1 m0dY wrote (Link) ()

Thanks sesser, all security concerned geeks owes you a lot on that

posted on Friday, December 22. 2006

#2 Ilia Alshanetsky wrote (Link) ()

The session patch is a clever idea, unfortunately it won't work in all cases. The code is based on uid of the script, which means that it'll work only in instances when the owner of the executed script is the user to whom the script belongs to.

However, if the user is using Smarty with template cache, or uploaded scripts via web control panel the user id of the script will be that of the web server. This means that for all such scripts the uid will be the same, effectively eliminating the fix, since there will no longer be a uid distinction between scripts "belonging" to different users on the system.

My suggestion would be to append to md5 checksum of the document root, or possibly the hostname to the session id.

posted on Saturday, December 23. 2006

#2.1 Stefan Esser wrote (Link) ()

How is safe_mode supposed to work with generated cached script files anyway?

The normal safe_mode rules will not allow the caching in files, because they are created and written with a different UID that cannot be opened or included.

posted on Tuesday, December 26. 2006

#3 Richard Thomas wrote (Link) ()

Your patch also assumes php is the only thing allowed to run on the server, Nothing php does can protect the session files from perl, ruby or other scripting languages that might have access as well.

Granted on a properly configured server this issue is migrated, but on a properly configured server you wouldn't need a patch for php anyway.

posted on Saturday, December 23. 2006

#3.1 Stefan Esser wrote (Link) ()

Yes we know other languages exist.

But their existance is irrelevant to the fact that PHP's safe_mode allows retrieving data belonging to another user, which by definition of safe_mode is not allowed.

posted on Saturday, December 23. 2006

#3.1.1 Ilia Alshanetsky wrote (Link) ()

Safe mode is flawed in that respect because bypassing it simply involves making a copy of the php script by another script. At that time to ownership of the new script is transfered to the web server and allows it to open (and even write) to any files owned by the web server as well.

posted on Saturday, December 23. 2006

#4 Peter Brodersen wrote (Link) ()

Wow - it's almost like it's christmas

Nice job. I do, however, like the idea of prefixing with servername, as mentioned in my first bugreport, #28242. UID might have some shortcomings as Ilia has mentioned.

But, once again, great job.

posted on Sunday, December 24. 2006

Add Comment

Name:

Email:

Homepage:

In reply to:

Comment:
Standard emoticons like :-) and ;-) are converted to images.

Remember Information? Subscribe to this entry
Submitted comments will be subject to moderation before being displayed.

Calendar