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.
|Component||Vulnerable Versions||Platform||Availability||Fix Available|
|Schedd daemon||8.9.3 and above||All platforms||Not known to be publicly exploited||9.0.10, 9.6.0|
|Status||Access Required||Host Type Required||Effort Required||Impact/Consequences|
|Verified||Ability to capture network traffic between Schedd and Startd or Collector||N/A||High||High|
|2022-03-15||Brian Bockelman, Jaime Frey|
An attacker must be able to capture network traffic between a condor_schedd and a condor_startd or condor_collector. The HTCondor daemons must be configured to use BLOWFISH or 3DES encryption (the default is AES in 9.0 and above) and match password authentication enabled (the default) to be vulnerable. A condor_schedd communicating to a version 8.8 peer is most likely to be vulnerable.Effort Required: High
A good understanding of the HTCondor network protocol and access to network traffic.Impact/Consequences Required: High
Using the secret information, an attacker could manipulate a user's running job, including evicting that job or replacing that job with one that executes the attacker's own code. The attacker could impersonate a condor_startd and cause the condor_schedd to send them a user's jobs for execution, allowing the attacker to read private data and return bogus results.Workaround:
Upgrading all HTCondor daemons to version 9.0.10 or 9.6.0 fully addresses this vulnerability.
If upgrading isn't possible, the easiest workaround is to ensure all machines are running HTCondor
9.0.0 or above, and that the
configuration parameters are either unset or list "AES" as the first
If some machines cannot be upgraded to 9.0.0 or above, then you can
configure all machines to use encryption for all communications.
To do this, set
SEC_DEFAULT_ENCRYPTION=REQUIRED and ensure no other
SEC_XXX_ENCRYPTION parameters set a different value.
In 9.0 and above, the configuration templates
use SECURITY: strong
use SECURITY: recommended_v9_0 also enable encryption.
If some of your execute or central manager machines cannot be upgraded
to 9.0.0 or above and their configuration cannot be altered to require
encryption, you can disable match password authentication on your
To do this, set
the configuration files.
Be advised that this may require additional configuration for
authentication and authorization between your submit and execute
It can also put significant extra load on your submit machines in a
large pool (thousands of nodes).
Embargoed until future notice.