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