Security hole in ChiliSoft ASP for Linux.


  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.


  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 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.


  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

 Affected systems:

  I tested and confirmed this problem on a RedHat Linux 6.2 machine
running RedHat 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.


  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.


  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(
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 [EMAIL PROTECTED]:

> 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.

Hey, did ya know something's beeping in the machine room?

Reply via email to