HTCondor (condor_startd, condor_schedd, condor_shadow): MULTI-TENANT ISOLATION: One CVE covering four separate

Impact

MULTI-TENANT ISOLATION: One CVE covering four separate authentication failures the HTCondor team disclosed together. The slot claim secret is written in the clear to STARTD_HISTORY and is also sent unencrypted on the wire when daemon-to-daemon encryption is off - either one lets an attacker seize another user's slot and run their own code as that user. Separately, a user with only READ authorization can perform WRITE operations on the job queue, and if CLAIMTOBE is in the READ method list (the default) they can submit and run jobs as any other user. On mixed Windows/Linux pools the shadow will also hand a user's stored Windows password to anyone authenticating as the condor service.

Who can reach it

Depends on the sub-issue: reading a world-readable file from inside your own job on an execute node; passively capturing schedd-to-startd traffic; or simply authenticating to the schedd with any READ-list method. The CLAIMTOBE variant needs nothing but network reach to a default-configured pool.

What to do

Upgrade to HTCondor 8.8.8 or 8.9.6 and restart all daemons. Independently of the patch, turn on daemon-to-daemon encryption, remove CLAIMTOBE from SEC_READ_AUTHENTICATION_METHODS, and disable match-password authentication in favour of a real method (SSL, Kerberos, TOKEN). Rotate any Windows credentials stored with condor_store_cred.

References