HTCondor 23.0.x before 23.0.22, 23.10.x before 23.10.22, 24.0.x before 24.0.6, and 24.6.x before 24.6.1 allows authenticated attackers to bypass authorization restrictions.

An issue was discovered in HTCondor 9.0.x before 9.0.10 and 9.1.x before 9.5.1. An attacker who can capture HTCondor network data can interfere with users' jobs and data.

An issue was discovered in HTCondor 9.0.x before 9.0.10 and 9.1.x before 9.5.1. An attacker can access files stored in S3 cloud storage that a user has asked HTCondor to transfer.

An issue was discovered in HTCondor 8.8.x before 8.8.16, 9.0.x before 9.0.10, and 9.1.x before 9.6.0. When a user authenticates to an HTCondor daemon via the CLAIMTOBE method, the user can then impersonate any entity when issuing additional commands to that daemon.

An issue was discovered in HTCondor 9.0.x before 9.0.4 and 9.1.x before 9.1.2. When authenticating to an HTCondor daemon using a SciToken, a user may be granted authorizations beyond what the token should allow.

An issue was discovered in HTCondor before 8.8.15, 9.0.x before 9.0.4, and 9.1.x before 9.1.2. Using standard command-line tools, a user with only READ access to an HTCondor SchedD or Collector daemon can discover secrets that could allow them to control other users' jobs and/or read their data.

condorcredd in HTCondor before 8.9.11 allows Directory Traversal outside the SECCREDENTIALDIRECTORYOAUTH directory, as demonstrated by creating a file under /etc that will later be executed by root.

HTCondor before 8.9.11 allows a user to submit a job as another user on the system, because of a flaw in the IDTOKENS authentication method.

HTCondor up to and including stable series 8.8.6 and development series 8.9.4 has Incorrect Access Control. It is possible to use a different authentication method to submit a job than the administrator has specified. If the administrator has configured the READ or WRITE methods to include CLAIMTOBE, then it is possible to impersonate another user to the condorschedd. (For example to submit or remove jobs)

The HTCondor scheduler can optionally notify a user of completed jobs by sending an email. Due to the way the daemon sent the email message, authenticated users able to submit jobs could execute arbitrary code with the privileges of the condor user.

Acknowledgements:

This issue was discovered by Florian Weimer of Red Hat Product Security.

The Condor S.E. (aka com.appcondorsoutheast.layout) application 1.399 for Android does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

A denial of service flaw was found in the way Condor's policy definition evaluator processed certain policy definitions. If an administrator used an attribute defined on a job in any of the following condorstartd policies (CONTINUE, KILL, PREEMPT, SUSPEND), a remote Condor service user could use this flaw to cause a denial of the condorstartd service by submitting a Condor job that caused certain policy definition to be evaluated to either ERROR or UNDEFINED states.

Workaround: =========== Check for UNDEFINED & ERROR in the policy configuration.

Multiple unspecified vulnerabilities in Condor 7.6.x before 7.6.10 and 7.8.x before 7.8.4 have unknown impact and attack vectors related to "error checking of system calls."

The filesystem authentication (condorio/condorauthfs.cpp) in Condor 7.6.x before 7.6.10 and 7.8.x before 7.8.4 uses authentication directories even when they have weak permissions, which allows remote attackers to impersonate users by renaming a user's authentication directory.

Multiple buffer overflows in Condor 7.6.x before 7.6.10 and 7.8.x before 7.8.4 have unknown impact and attack vectors.

Florian Weimer of the Red Hat Product Security Team found that an unauthenticated user able to connect to the Condor startd TCP port could request ads, provided they could guess or brute force the PID of the process, due to how the GIVEREQUESTAD handler is registered. The ads contains a lot of already-public information for users with READ privileges, however it also provides the ClaimId (as opposed to the PublicClaimId which truncates the full value of the ClaimID). If an attacker could obtain the private ClaimId, they could use it to control the running job, and also start new jobs on the system.

Multiple format string flaws were found in Condor:

a) when the XML message log format was requested in Condor submit job by remote Condor user and that user attempted to write a specially-crafted message into user log file via condorhold tool it could lead to condorschedd daemon crash, or, potentially arbitrary code execution with the privileges of the 'condor' user []. Also this way an attacker could potentially prevent other Condor jobs from being scheduled and ever executed,

b) request for file transfer by remote Condor user to transmit a file, with specially-crafted name, could lead to child process of condorschedd daemon to crash (repeated process, where condorschedd daemon would fork a child process to handle the request, the child to crash, while trying to handle it and condorschedd daemon to fork another child since the particular Condor job still have not been completed successfully).

Upstream bug report (mentioning only one attack vector): [1] https://condor-wiki.cs.wisc.edu/index.cgi/tktview?tn=2660

General upstream patch (addressing among these flaws also couple of compiler warning problems): [2] http://condor-git.cs.wisc.edu/?p=condor.git;a=commitdiff;h=5e5571d1a431eb3c61977b6dd6ec90186ef79867

-- [] Arbitrary code execution was possible only on systems, where Condor daemons were not compiled with FORTIFYSOURCE protection mechanism. On systems with this protection enabled, particular flaw would lead to Condor service crash only.

Condor 6.5.4 through 7.2.4, 7.3.x, and 7.4.0, as used in MRG, Grid for MRG, and Grid Execute Node for MRG, allows remote authenticated users to queue jobs as an arbitrary user, and thereby gain privileges, by using a Condor command-line tool to modify an unspecified job attribute.

Unspecified vulnerability in the condor schedd daemon in Condor before 7.0.5 allows attackers to cause a denial of service (crash) via unknown vectors.

Stack-based buffer overflow in the condor schedd daemon in Condor before 7.0.5 allows attackers to cause a denial of service (crash) and possibly execute arbitrary code via unknown vectors.

Condor before 7.0.5 does not properly handle when the configuration specifies overlapping netmasks in allow or deny rules, which causes the rule to be ignored and allows attackers to bypass intended access restrictions.

Unspecified vulnerability in Condor before 7.0.5 allows attackers to execute jobs as other users via unknown vectors.

Condor before 7.0.4 does not properly handle wildcards in the ALLOWWRITE, DENYWRITE, HOSTALLOWWRITE, or HOSTDENYWRITE configuration variables in authorization policy lists, which might allow remote attackers to bypass intended access restrictions.