A user who has an IDToken with restricted authorization could perform some operations that should be denied by those restrictions. They would still be constrained to the authorization levels granted to the IDToken's identity in the HTCondor configuration files.

An attacker needs an IDToken that can be validated by the targeted daemon (i.e. the daemon has access to the token's sigining key). The attacker does not need to be granted access by the daemon's configured authorization policy.

An attacker does not need to write custom tools.

This attack allows a user to perform all actions to which their HTCondor identity is entitled via daemons' authorization policy. This is the same level of access available when using most other forms of authentication (FS, NTSSPI, SSL, KERBEROS, MUNGE) for the same identity.

You are potentially at risk if you have run any of the following commands:

• condor_token_create with the -authz option
• condor_token_fetch with the -authz option
• condor_token_request with the -authz option
• condor_token_request_approve
• condor_token_request_auto_approve
• condor_scitoken_exchange

Upgrading all HTCondor daemons to version 23.0.22, 23.10.22, 24.0.6 or 24.6.1 fully addresses this vulnerability.

If upgrading isn't possible, you can mitigate this issue by constraining new IDTokens issued by a daemon to have no authorizations. Add this to your configuration files:

SEC_TOKEN_REQUEST_LIMITS = DENY

SEC_ISSUED_TOKEN_EXPIRATION = 0

If you fear that this vulnerability has already been exploited on your systems, you should replace all of your IDToken signing keys and issue new tokens using the new keys. Also, please email us at htcondor-security@cs.wisc.edu.

Embargoed until future notice.