ASP (Active Server Pages) are a technology initially developed by Microsoft to tackle the "dynamic content on the web" problem. Chili!Soft is a company that has released a piece of software called Chili!Soft ASP that makes ASP functionality available on . . .
ASP (Active Server Pages) are a technology initially developed by Microsoft to tackle the "dynamic content on the web" problem. Chili!Soft is a company that has released a piece of software called Chili!Soft ASP that makes ASP functionality available on other operating systems and webservers, such as Linux, Solaris and AIX, HP-UX, Apache, iPlanet, Lotus Domino and O'Reilly Website Pro.

 Date: Tue, 6 Feb 2001 17:00:07 -0500 From: Mark Krenz  To: BUGTRAQ@SECURITYFOCUS.COM Subject: Security hole in ChiliSoft ASP on Linux.
Synopsis:

Under Un*x systems you can set the ChiliSoft ASP (CASP) daemon to run in one of two different security modes. The first one is defined mode, where you specify that the daemon be started as root and then run as the user you specify in the casp.cnfg configuration file. As an example, this mode would be useful on a company who runs their own webserver and uses one single user to own all their web content.

The second mode that CASP can be run in is inherited mode. In this mode, the server is started by root and inherits the user and group information from each virtual host in the Apache webserver. So if a virtual domain called https://www.xyz.org was setup under Apache with the directives "User john" and "Group vhttp", any script run in that domain's webspace would run as the user john and the group vhttp. And thus the scripts would be restricted to accessing files based on the access allowed to that user and group. This is useful for ISPs that have webservers that are shared by many different virtual domain customers.

Problem:

While running CASP in the inherited security mode, none of the ASP scripts running under a user's virtual webspace inherit the group that is specified with the Group directive in the domain's virtual host container. So while the scripts end up running as the user specified with the User directive, they end up running as group root. This kinda defeats the whole purpose of inherited mode and is a major security problem.

Affected systems:

I tested and confirmed this problem on a Red Hat Linux 6.2 machine running Red Hat SecureWebServer 3.2.1, which is basically Apache 1.3.9 with mod_ssl. I am unable to test this on Solaris or any other Un*x platform so I'm unsure if the problem exists on other OSes. Chili!Soft didn't specify whether the problem existed on other platforms. Solutions:

Chili!Soft informed me that this problem is fixed in their upcoming 3.6 release of Chili!Soft ASP which they claim is due out in the first quarter of 2001.

A temporary solution might be to change your security mode to defined user mode by setting inherit_user=0 and specifying a user and group to run as in the casp.cnfg file.

History:

For a few days after I setup ChiliSoft ASP I was trying to figure out why inherited user mode wasn't working. I was testing it's ability to run in inherited mode by creating an ASP script that read a file mode 644 in root's home directory (the directory is mode 750 owned root.root). I figured that this was a good real situation to test whether the inheritance was working or not. I later tried to read another file in the same directory with permissions that restricted the root group (mode 600) from reading the file. That's when I realized that it was inheriting the root group, which was enabling it to get through to the root directory.

I then went to Chili!Soft's support forum(https://www.oracle.com/) to look for other instances where this problem might have been mentioned. I found none so I posted my own message to their forum explaining the problem. After waiting a half a day and receiving no response to my message on their forum I wrote to their tech support address with a duplicate copy of the message that I posted to their support forum. I received this response the same day from eval@chilisoft.com:

 > This is a known issue with the software, and has been addressed in the > upcoming 3.6 round of releases.  This is due on both Solaris and Linux > this quarter.  We're in QA at this point, and this particular issue has > been resolved.  Thank you for your interest in our product.
I wrote them back and explained that this is a big security issue and should be resolved quickly and that if they knew about the problem they should have notified customers of the problem. They have only written me back since stating that the current release must go through many tests in Quality Assurance before they can release it to the public.

It has now been a week since I initially notified Chili!Soft of the problem. There has been no real solution, so I'm posting to BugTraq.