GRATIA-CONDOR-2010-0001


Summary:

 

The Gratia Condor probe is prone to a Denial of Service vulnerability. As a result of this attack, the Gratia Condor probe does not collect the data and send it to the collector thereby causing potential loss of data.


Component Vulnerable Versions Platform Availability Fix Available
condor_meter 1.04.4d-1
1.06.13b-1
all not known to be publicly available no
Status Access Required Host Type Required Effort Required Impact/Consequences
Verified local ordinary user host running Gratia Condor probe low low
Fixed Date Credit
  Rohit Koul

Access Required:

local ordinary user

The vulnerability requires the user to have a local account on the host running Gratia Condor probe.

Effort Required:

low

Exploiting this vulnerability requires the user to be able to write and execute a simple script.

Impact/Consequences:

low

While the exploit is running, the Gratia Condor probe cron job does not function. This results in the data from the target host not being updated in the Gratia collector and the probe being marked inactive. If this data is removed by a cleaner application, then it is permanently lost.

Full Details:

 

condor_meter.cron.sh attempts to check if condor_meter.pl is already running on the host. However, the code just checks for the literal name condor_meter.pl without checking the ownership of the said process, and exits in case of a match. Any user can essentially run a simple perl script with the same name indefinitely thereby causing a match and preventing the actual meter from running.

The exploit is just a perl script with the name condor_meter.pl, that runs indefinitely.

An example attack is shown in the perl script below.

     #!/usr/bin/perl
     # Filename:  condor_meter.pl

     while(1) {
         sleep 1000;
     }
  

Cause:

invalid assumption

The cause of the vulnerabiity is an incorrect assumption that a process running with the name condor_meter.pl is the Gratia Condor probe started by the crond daemon.

Proposed Fix:

 

One possible solution is the usage of a pid file (a text file named name-of-the-executable.pid containing the process id of the executable). Generally, programs in such cases, create a pid file under /var/run when they start and remove it on quitting. The executable is coded to start only if the pid file does not exist. This way only one copy of the process is run by a user at a given time.

Another possible, but less elegant solution is to check for the ownership of the condor_meter.pl process. For example, a shell script can be used to get the number of processes with the name condor_meter.pl and owned by root which can be accomplished with the following code:

     ps -u root -o comm | grep condor_meter.pl | wc -l 
  

Actual Fix:

 

The condor_meter_cron.sh cron script was modified to write its pid to a text file and the proposed fix as outlined above was followed.

Acknowledgment:

 

This research funded in part by Department of Homeland Security grant FA8750-10-2-0030 (funded through AFRL).