Lucene search
K

cobalt.cgiwrap.txt

🗓️ 09 Nov 1999 00:00:00Reported by Chris AdamsType 
packetstorm
 packetstorm
🔗 packetstormsecurity.com👁 26 Views

Vulnerabilities in Cobalt RaQ2 cgiwrap allow unauthorized CGI execution and user impersonation risks.

Code
`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.  
  
I notified Cobalt 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.  
--  
Chris Adams <[email protected]>  
Systems and Network Administrator - HiWAAY Information Services  
I don't speak for anybody but myself - that's enough trouble.  
  
`

Data

Build on a solid foundation with Vulners data

We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data

Api

Power your application with Vulners API

The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access

App

Assess and manage vulnerabilities with Vulners tools

Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation