COMMAND
cgiwrap
SYSTEMS AFFECTED
Cobalt RaQ 2 and RaQ 3i cgiwrap
PROBLEM
Chris Adams found following. There is a problem (actually
several) with the "cgiwrap" program on Cobalt RaQ2 servers. It
is supposed to run CGI programs as the proper user instead of
"nobody" to make CGIs a little more secure. The Cobalt directory
structure is as follows:
/home/sites/site1/ - top level directory of the site (site1, site2, ...)
/home/sites/site1/web - top level directory of the web site
/home/sites/site1/users/*/web - top level directory of web
sites for individual users
(like ~user/public_html)
CGI scripts in the site /web directory should run as the user
that owns the script and the site1 group (each site has its own
group). Instead, they run as user "nobody" group "nobody".
The bigger problem is that cgiwrap apparently interprets top level
directories of the site /web directory as users. So if you have
a CGI in a directory like /home/sites/site1/web/test/test.cgi and
attempt to go to it at http://www.site1.com/test/test.cgi AND
there is a user on the system named "test", cgiwrap thinks it
should run the script as user "test". It then actually attempts
to run a script in /web directory of the user "test".
This can be used to break other sites on a RaQ2 in several ways.
First of all, if there is are two sites on the system, and one
has CGI scripts (say for example "submit.cgi") in a subdirectory
of their site /web directory called "scripts", the admin(s) of
the second site can keep any scripts in that directory from
running by creating a user named "scripts" (cgiwrap will give a
"file not found" error). Second (and more serious for e-commerce
type sites), if the second admin then creates programs with the
same name in the users/scripts/web directory, they will be run
when requests for the first site are made.
When someone calls http://www.site1.com/scripts/submit.cgi,
http://www.site2.com/users/scripts/submit.cgi will be run
(transparently). First, that will break site1, but it also can
lead to private information being submitted to site1 being
submitted to site2 instead. This is the biggest security problem.
SOLUTION
Cobalt was notified about this several weeks ago now, and they've
said they are working on it, but that is it. They haven't
released any kind of notice or update as of yet either.
This is specific to the modifications that Cobalt has made to
cgiwrap for their server's structure. It is not an issue with the
regular version of cgiwrap.
Cobalt has an updated package available on their FTP site. It
appears to fix all of the bugs found, and changes the behavior
some. Instead of running scripts in the site's /web directory as
user "nobody" and the site's group, it runs them as the owner of
the script, _if_ that user is a member of the site's admin group.
Patches:
RaQ 3i (x86)
ftp://ftp.cobaltnet.com/pub/experimental/secuirty/rpms/cgiwrap-pacifica-3.6.4.C5.i386.rpm
ftp://ftp.cobaltnet.com/pub/experimental/secuirty/srpms/cgiwrap-pacifica-3.6.4.C5.src.rpm
RaQ 2 (MIPS)
ftp://ftp.cobaltnet.com/pub/experimental/secuirty/rpms/cgiwrap-raq2-3.6.4.C5.mips.rpm
ftp://ftp.cobaltnet.com/pub/experimental/secuirty/srpms/cgiwrap-raq2-3.6.4.C5.src.rpm