CVE-2021-20179: Fix renewal profile approval process - v10.11 #3474
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Due to a recent change in PKI CLI, the CLI now passes along user authentication with submissions to the renewal endpoint. Unlike the EE pages, the REST API has passed along this authentication for a while. Due to a bug in the RenewalProcessor, requests with credentials against profiles with no authentication method and no ACLs result in the certificiate automatically being approved. This occurs because, when an earlier commit (cb9eb96) modified the code to allow Light-Weight SubCAs to issue certificates, validation wasn't done on the passed principal, to see if it was a trusted agent. Because profiles requring Agent approval have an empty ACL list (as, no user should be able to submit a certificate request and have it automatically signed without agent approval), authorize allows any user to approve this request and thus accepts the AuthToken. Critical analysis: the RenewalProcessor code interprets (authToken != null) as evidence that the authenticated user is /authorized/ to immediately issue the certificate. This mismatch of concerns (authn vs authz) resulted in a misunderstanding of system behaviour. The "latent" AuthToken (from the HTTP request) was assigned to authToken without realising that authorization needed to be performed. We fix this by splitting the logic on whether the profile defines an authenticator. If so, we (re)authenticate and authorize the user according to the profile configuration. If the profile does not define an authenticator but there is a principal in the HTTP request, if (and only if) the user has permission to approve certificate requests *and* the requested renewal profile is caManualRenewal (which is hardcoded to be used for LWCA renewal), then we issue the certificate immediately. This special case ensures that LWCA renewal keeps working. Otherwise, if there is no principal in the HTTP request or the principal does not have permission to approve certificate requests, we leave the authToken unset. The resulting renewal request will be created with status PENDING, i.e. enqueued for agent review. Signed-off-by: Fraser Tweedale <ftweedal@redhat.com> Signed-off-by: Alexander Scheel <ascheel@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Due to a recent change in PKI CLI, the CLI now passes along user
authentication with submissions to the renewal endpoint. Unlike the EE
pages, the REST API has passed along this authentication for a while.
Due to a bug in the
RenewalProcessor, requests with credentials againstprofiles with no authentication method and no ACLs result in the
certificiate automatically being approved. This occurs because, when
an earlier commit (cb9eb96) modified
the code to allow Light-Weight SubCAs to issue certificates, validation
wasn't done on the passed principal, to see if it was a trusted agent.
Because profiles requiring Agent approval have an empty ACL list (as, no
user should be able to submit a certificate request and have it
automatically signed without agent approval), authorize allows any user
to approve this request and thus accepts the AuthToken.
Critical analysis: the
RenewalProcessorcode interprets (authToken!= null) as evidence that the authenticated user is authorized toimmediately issue the certificate. This mismatch of concerns (
authnvs
authz) resulted in a misunderstanding of system behaviour. The"latent"
AuthToken(from the HTTP request) was assigned toauthTokenwithout realising that authorization needed to be performed.
We fix this by splitting the logic on whether the profile defines an
authenticator. If so, we (re)authenticate and authorize the user
according to the profile configuration.
If the profile does not define an authenticator but there is a
principal in the HTTP request, if (and only if) the user has
permission to approve certificate requests and the requested
renewal profile is
caManualRenewal(which is hardcoded to be usedfor LWCA renewal), then we issue the certificate immediately. This
special case ensures that LWCA renewal keeps working.
Otherwise, if there is no principal in the HTTP request or the
principal does not have permission to approve certificate requests,
we leave the authToken unset. The resulting renewal request will be
created with status PENDING, i.e. enqueued for agent review.
References: CVE-2021-20179
Resolves: rh-bz#1914379