Possible widespread PHP configuration issue - security risk

[Adam Younce]

On Aug 27, 2010, at 11:41 AM, Ed W wrote:

>  Hi
> 
>> The simplest solution to the problem presented would be to change the wiki to encourage users to set their upload directory to a location not served by nginx (and thus not executable by PHP). This is *entirely* a PHP configuration issue.
> 
> I *think* I'm right in saying this is going to be more down to 
> application support than a PHP issue?  A few applications *do* move 
> their upload directory outside of the document path (Gallery 2 comes to 
> mind). However, the vast majority don't seem to.  Further I don't see 
> how this can be changed in general since it would require the 
> application to then proxy all requests for those assets?
> 
> Mediawiki for example does it's best to parse uploads and check they are 
> safe, but after that it stuff them in the /images/ directory and leaves 
> it up to your webserver to serve them (which leaves open the possibility 
> that the webserver might inadvertently process them as some kind of cgi 
> or SSI or whatever)

Your Mediawiki example shows that trying to solve this at the nginx level is flawed. There isn't really a best practice  (that I can think of) that allows execution of PHP files across an unknown directory structure *and* keeps potentially exploitable locations safe in *all* canned PHP apps. It's an application level problem. Securing poorly designed apps via nginx is certainly something that should be done, but I don't see how we can help solve the problem outside of strongly recommending that people be restrictive in their configurations (which will vary wildly).

>> There are still dangers depending on what the application does with the uploaded files, but those exist no matter what. Making the change to the documentation to encourage this best practice should suffice for us.
> 
> Actually I believe we can do better...
> 
> The documentation bit is to warn users that SSI/CGI/dir listing/etc 
> should be disabled on any location that the users can upload  to.  
> However, I think we can provide some default nginx config which does 
> this efficiently.

It's not so much that we need to disable locations that people can upload to (upload_tmp_dir in PHP is usually outside the served directory structure by default) as disable locations that PHP apps then *move* those files to. This is fairly difficult as it's all up to the app in question.

> I have already proposed by lame attempt at this, but I'm hoping someone 
> will show something much neater, possibly involving try_files and a @php 
> location?  After that I think we have a great starting point for a 
> generic CGI entry and this can migrate to all the other wiki entries 
> after that
> 
> Please don't forget about SSI and all other server side processing which 
> can be abused.  ALL of this stuff should be turned off for untrusted 
> content in general.  This isn't a new warning... It's just that most 
> config examples aren't showing how to do this for nginx (apache tends to 
> be the default)

I'm 100% with you that the docs need to be expanded to clearly communicate the dangers and provide a solid starting point. I don't know that we can provide an air-tight default configuration though.

> Cheers
> 
> Ed W


Let me say that I'm very grateful that someone has taken up this torch. It's a problem that needs to be addressed.

--

Adam Younce
ayounce at ripcord.net