Forum

Hiawatha version: 7.8.2
Operating System: Fortress Linux

Hello Hugo,

We are creating a new secure website and we noticed the following:

* We have a file "example.php" that is chown as PHPCGI:HIAWATHA and it has chmod 400.
* PHP-FCGI is running as user PHP-CGI and Hiawatha is running as user HIAWATHA

Normally Hiawatha will give a 403/404 error when accessing a file with these permissions, but if it is a .php file, Hiawatha doesn't check the permission and it executes the .php file through php-cgi instead of denying access to it.

Is this normal?

Hiawatha doesn't check file permissions when executing a CGI via FastCGI. It's because the FastCGI could be located on a remote server, in which case Hiawatha can't check the file's permissions. It leaves that check to the FastCGI application itself.

So, yes. This is normal behavior.

Great,

This also means that Hiawatha can access an included or off-limit .php file that only should be accessible by PHPCGI.

is there any way to undo this behaviour besides using a toolkit rule for every file?

Only by changing the code...

In my view, 95% of the Hiawatha users will not use an external PHP CGI server and for multiple reasons. Maybe it is interesting to add a new configure option to .configure?

Where can I find the responsible instruction in the source-code?

Never mind, I wrote a patch myself for this exploit.

What do you mean by exploit? In what way is Hiawatha's behaviour exploitable?

Are you willing to share your patch?

What do you think what can happen when Hiawatha ignores its own file permissions?

My patch for 7.8.2:

*** target.c.old	Fri Nov 18 07:06:12 2011
--- target.c	Tue Feb  7 18:18:38 2012
***************
*** 487,493 ****
  		session->keep_alive = false;
  	}
  
- 	if ((wrap_cgi == false) && (session->cgi_type != fastcgi)) {
  		if ((handle = open(session->file_on_disk, O_RDONLY)) == -1) {
  			if (errno == EACCES) {
  				log_error(session, fb_filesystem);
--- 487,492 ----
***************
*** 497,503 ****
  		} else {
  			close(handle);
  		}
- 	}
  
  	if (session->host->execute_cgi == false) {
  		log_error(session, "CGI execution not allowed");
--- 496,501 ----

Well, nothing. The permissions are checked by the FastCGI application or the CGI-wrapper. Your patch doesn't add anything to security, it only cripples the webserver. Without your 'patch', you can run a FastCGI deamon under a different userid and by so, making scripts and their configuration files inaccessible for other websites on the same webserver.

Nice spin, like that TLS v1.0 BEAST weakness in PolarSSL for Hiawatha 8.0.
You know we have a higher security demand then yours. Protect it before it can be exploited. Not after... We of Fortress Linux call this Pro-Active security.

But preventing unwanted file 'inclusions' on shared hosting is, among other, the whole intention of this patch. Hiawatha should first obey the default Linux/Unix filesystem permissions before it tries to pass/execute a php script.

When Hiawatha is not allowed to read it, Hiawatha should not pass it to PHP-CGI. The patch works perfectly for our situation.

So you tell me that some people are really sending PHP-CGI data over a possibly insecure network that can be sniffed and spoofed? Ever tried to send a spoofed replay IP package with nasty PHP code to the PHP-CGI server?

The operating system prevents unauthorized file access. Checking if the operating system will block access before trying to read it, doesn't add much to security. A FastCGI daemon will only be able to read files the operating system allows it to read.

In case of PHP, Hiawatha will only send requests for PHP files to the daemon (configured via file extensions). In case of a catch-all FastCGI daemon, it's up to the daemon which file is read. Hiawatha can't do anything about it.


This is not true. If I want to run CGI scripts with a different userid that Hiawatha' usedid, you can do so by running the FastCGI daemon with a different userid. You patch makes this no longer possible.


This is a total different issue and has nothing to do with checking file-permissions. And this issue can easily be solved via a SSL-tunnel.

Hugo, We currently have Hiawatha running as user 'hiawatha' and PHP-FCGI running as user 'php-cgi' instead of running them both as user 'nobody', which is the (insecure) default. Two network daemons should never run under the same ID if you take security seriously.

A real-live example: Many CMS websites have a file in their root that is called "install.php" And allowing Hiawatha to access it could damage your websites database.

But this file still has to be accessible by user "php-cgi" to perform updates and checks within the CMS itself. The CMS uses PHP code to execute and instruct the install.php file and therefore Hiawatha is not needed to read them directly.

Before this patch, we were able to access and execute "install.php" with Hiawatha, even though user "hiawatha" didn't have read access for it. (When hiawatha cannot read a PHP file, It simply passes the PHP file to PHP-CGI, which has reading permissions for it?)

After this patch, Hiawatha gave a 404 error for all the files that didn't have read permissions on it for user "hiawatha", instead of passing it to PHP-CGI that was allowed to execute it. The website still works flawlessly.

Yes, you can encrypt PHP-CGI traffic and use a firewall and such, but that would be like using encryption between your motherboard and hard-disk controller -> dreadfully slow due to encryption overhead.