HTCSS Vulnerability Reports

HTCONDOR-2022-0003
When a user authenticates to an HTCondor daemon using the CLAIMTOBE method, the user can then impersonate any entity when issuing additional commands to that daemon.
HTCONDOR-2022-0002
A piece of secret information is sent over the network in the clear if the administrator has configured weaker encryption protocols or if some of the HTCondor daemons are version 8.8 or earlier. An attacker could use this secret information to control the slot of another user, including running their own code as that user. An attacker could also impersonate a condor_negotiator and condor_startd, tricking the condor_schedd into sending them the jobs of any user.
HTCONDOR-2022-0001
For jobs that request HTCondor to transfer files to or from S3 cloud storage, pre-signed URLs that can be used to access private files are written to daemon logs and the job ad.
HTCONDOR-2021-0004
When authenticating to an HTCondor daemon using a SciToken, a user may be granted authorizations beyond what the token should allow.
HTCONDOR-2021-0003
Using standard command-line tools, a user with only READ access to a SchedD or Collector can discover secrets that could allow them to control other users jobs and/or read their data.
HTCONDOR-2021-0002
A running condor_credd daemon can be instructed to create or write certain files as root that are outside of the directory specified by the parameter "SEC_CREDENTIAL_DIRECTORY_OAUTH".
HTCONDOR-2021-0001
When a user is authenticating to a daemon using IDTOKENS it is possible for them to impersonate other users and/or the "condor" service itself.
HTCONDOR-2020-0004
On Windows, the condor_shadow will send a user's password to anyone who can present credentials that authenticate them as the condor service.
HTCONDOR-2020-0003
A user with read-only authorization to access the job queue is able to perform write operations under their identity, including submitting new jobs. If CLAIMTOBE is part of the READ authentication methods, then the user is able to impersonate any other user when modifying the job queue. This includes submitting and running jobs as any other user. By default, CLAIMTOBE is included in the list of methods for READ access.
HTCONDOR-2020-0002
A piece of secret information is sent over the network in the clear if the administrator has not enabled daemon-to-daemon encryption. For pools configured without daemon-to-daemon encryption, an attacker could use this secret information to control the slot of another user, including running their own code as that user.
HTCONDOR-2020-0001
A piece of secret information is written in the clear to the STARTD_HISTORY file. An attacker could use this secret information to control the slot of another user, including running their own code as that user.
HTCONDOR-2017-0001
An attacker can potentially cause the condor_schedd to crash.
HTCONDOR-2014-0001
An attacker can potentially gain unauthorized access to jobs.
CONDOR-2012-0003
A user can potentially submit jobs which run code locally on the submit machine as root.
CONDOR-2012-0002
A malicious user can potentially circumvent host-based authorization controls.
CONDOR-2012-0001
A malicious user can crash the condor_schedd, causing a denial of service to other submitters.
CONDOR-2009-0001
An ordinary user that can submit jobs to a Condor system can modify any of the attributes of its Condor job. This in turn can be used to compromise other users' jobs, which can lead to a complete compromise of the local accounts in the Condor system other than the local privileged accounts (root on POSIX systems and local\Administrator on Windows).
CONDOR-2008-0004
User supplied input to condor_qedit can cause the condor_schedd to crash and not be able to recover.
CONDOR-2008-0003
User supplied input to condor_qedit can cause the condor_schedd to crash or potentially allow the execution of arbitrary code.
CONDOR-2008-0002
If a server is using IP based authentication, in certain configurations the set of IP addresses that are allowed can be more permissive than expected when denying IP addresses. This can allow an attacker to perform actions against the Condor daemon that should not be allowed.
CONDOR-2008-0001
It is possible for a user that can submit jobs to a condor_schedd to modify arbitrary attributes of the job, including attributes an ordinary user should not be able to modify. For instance, a user can change the owner of their job to run as any non-root user.
CONDOR-2006-0009
It is possible to update a class ad in the collector, such that the contents of the class ad can cause a buffer in the condor_negotiator to overflow. This can result in a crash, or potentially a root compromise of the condor_negotiator. This compromise requires the user to be able to use the condor_advertise command. This is the case for ordinary users, if host-based authorization is used on machines running Condor daemons, which includes all submission and execution hosts.
CONDOR-2006-0008
On Windows platforms and potentially some old versions of UNIX, if the persistent configuration changes are allowed, then it is possible that an attacker may be able to change the configuration of the machine, which could lead to a root compromise. Persistent configuration changes through the use of condor_config_val is disabled by default, which prevents this vulnerability.
CONDOR-2006-0007
Condor users can use public key certificates as a means of authentication when using the GSI or SSL authentication methods. It is possible to spoof a signature if a PKCS #1 1.5 signature with an RSA key of exponent 3 is used. This can lead to identity spoofing through the use of a malformed signature. The use of this particular type of key seems to be rare.
CONDOR-2006-0006
The use of FS or FS_REMOTE authentication methods can result in a spoofing of identity if an attacker has access to the file system used to perform the authentication.
CONDOR-2006-0005
A user that is able to submit a Condor job can modify jobs or add arbitrary jobs to the job queue if they can force a restart of the condor_schedd to which they submit jobs. The user has complete control of the job attributes, including the user and executable.
CONDOR-2006-0004
In the rare configuration that CLASSAD_SCRIPT_DIRECTORY is set in the Condor configuration, arbitrary executables can be executed with the permissions of the condor_negotiator and condor_shadow's effective uid (normally the "condor" user). This can result in a compromise of the condor configuration files, log files, and other files owned by the "condor" user. This may also aid in attacks on other accounts.
CONDOR-2006-0003
In the rare configuration that CLASSAD_SCRIPT_DIRECTORY is set in the Condor configuration, arbitrary commands can be executed with the permissions of the condor_negotiator and condor_shadow's effective uid (normally the "condor" user). This can result in a compromise of the condor configuration files, log files, and other files owned by the "condor" user. This may also aid in attacks on other accounts.
CONDOR-2005-0004
Arbitrary configuration options can be set if a user has access to the "condor" user account that Condor components run as, even if all the configuration files are owned by root. This can lead to a denial of service, or a complete root compromise of the system if the condor_master is started as root.
CONDOR-2005-0003
Arbitrary commands can be executed with the permissions of the condor_shadow or condor_gridmanager's effective uid (normally the "condor" user). This can result in a compromise of the condor configuration files, log files, and other files owned by the "condor" user. This may also aid in attacks on other accounts.
CONDOR-2005-0001
Condor checkpoint server allows reading and writing of arbitrary files with the permissions of the condor_ckpt_server's effective uid (normally the "condor" user) from a remote machine with no special privileges. This can result in checkpoints being replaced with malicious versions, reconfiguring condor if the "condor" user owns the configuration files, or gaining access to system files which may aid in other attacks.