HTCONDOR-2020-0001


Summary:

 

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. CVE-2019-18823


Component Vulnerable Versions Platform Availability Fix Available
condor_startd All before 8.8.8 (stable) and 8.9.6 (devel) all not known to be publicly exploited 8.8.8, 8.9.6
Status Access Required Host Type Required Effort Required Impact/Consequences
Verified login access to an execute machine or the ability to submit a job execute hosts that are not configured to use authentication or use match password authentication high high
Fixed Date Credit
2020-03-01 Todd Tannenbaum

Access Required:

Be able to read a world-readable file on an execute machine. Even if a user does not have login access to the execute machine, the attacker can submit a job and that job can then look at the STARTD_HISTORY on the machine where it executes. Execute machines configured to require a strong credential-based authentication method (e.g. authentication method such as pool password, SSL, Kerberos, GSI, or TOKEN) and have match password authentication disabled are not vulnerable.

Effort Required:

high

A thorough understanding of the HTCondor code and the ability to write custom tools is required to exploit this vulnerability. Also, the pool must be using host-based authorization or have match password authentication enabled (the default) to be vulnerable. If authentication has been set up for the pool and match password authentication is disabled, the attacker would also need to gain access to the condor credentials.

Impact/Consequences:

high

Using the secret information, they could then manipulate another user's running job, including evicting that job or replacing that job with one that executes the attacker's own code. This could possibly allow the attacker to get access to the user's job data files which may contain sensitive information. Pools that are not configured to use daemon-to-daemon authentication or have match password authentication enabled (the default) are vulnerable.

Workaround:

Disable STARTD_HISTORY, which is on by default. You can do this by adding "STARTD_HISTORY=" in your condor_config file.

Alternatively, the administrator can configure authentication for daemon-to-daemon communications and disable match password authentication. To disable match password authentication, add "SEC_ENABLE_MATCH_PASSWORD_AUTHENTICATION=False" to your condor_config file. See the security section of the manual for more information about configuring daemon-to-daemon authentication. Be advised that disabling match password authentication can put significant extra load on the submit machines of a large pool (thousands of nodes).

After installing updated binaries or working around the issue, you should restart HTCondor. The secret written to the log will no longer be relevant and you do not need to scrub or delete the log.

Full Details:

Embargoed until future notice.