[ https://issues.apache.org/jira/browse/KAFKA-17345 ]
Tim Fox deleted comment on KAFKA-17345:
---------------------------------
was (Author: purplefox):
Adding a bit more information:
* I think the fix should be straightfoward - ScramSaslServer needs to keep
track of the nonce sent back in response 1 and verify that it's the same as the
none received in request 2. Here's the equivalent check in xdg-go
[https://github.com/xdg-go/scram/blob/master/server_conv.go#L129]
* Fixing this will break librdkafka - as librdkafka currently sends an
incorrect nonce in request 2. So any fix will need to co-ordinate with that
team to avoid breaking user apps.
* The Kafka Java client looks at first glance to be sending the correct nonce,
so should not break. (Needs to be verified).
> Client nonce is not checked during SASL-SCRAM-256 authentication
> ----------------------------------------------------------------
>
> Key: KAFKA-17345
> URL: https://issues.apache.org/jira/browse/KAFKA-17345
> Project: Kafka
> Issue Type: Bug
> Components: security
> Affects Versions: 3.8.0
> Reporter: Tim Fox
> Priority: Critical
>
> It appears that the SCRAM server side implementation in Apache Kafka is not
> checking that the nonce sent during the second request from the client during
> authentication using SASL-SCRAM-256 is the same as the nonce returned from
> the server in the first response from the server.
> SCRAM RFC is here [https://datatracker.ietf.org/doc/html/rfc5802]
> The part of the RFC that says the client returns the same response that it
> received from the server is here:
> {quote}The client then responds by sending a "client-final-message" with the
> *same nonce* and a ClientProof computed using the selected hash function as
> explained earlier.
> {quote}
>
> Here's the part of the RFC saying to check nonces:
> {quote}The server *_verifies the nonce_* and the proof, verifies that the
> authorization identity (if supplied by the client in the first
> message) is authorized to act as the authentication identity, and, finally,
> it responds with a "server-final-message", concluding the authentication
> exchange.
> {quote}
> It appears that latest Apache Kafka _does not_ verify the nonces are the
> same, contrary to the RFC. I.e.
> [https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/common/security/scram/internals/ScramSaslServer.java#L152]
> - i.e. there is no check on the nonce.
>
> According to the RFC, verifying the nonce on the server is *not* optional:
> {quote}
> The server MUST verify that the nonce sent by the client in the second
> message is the same as the one sent by the server in its first message.
> {quote}
> I stumbled upon this while creating a Kafka compatible server in golang and
> using the xdg golang library - which is known to be strictly RFC compliant.
> [https://github.com/xdg-go/scram]
> This implementation *does* check that the nonce sent from the client in the
> second request is the same as the one returned from the server in the first
> request, and this results in an authentication failure when using it with a
> librdkafka client as it appears that librdkafka *does not* send the same
> nonce it received from the server in the second request. I have filed a
> related issue with librdkafka to cover that:
> [https://github.com/confluentinc/librdkafka/issues/4814]
> In summary, this means, that a client (for example librdkafka) which sends an
> incorrect nonce in the second request of SASL-SCRAM-256 authentication
> (contrary to the RFC) can still pass authentication with Apache Kafka.
> I am not a security expert and I do not know if this enables an exploit or
> vulnerability in Apache Kafka, but I have filed this as critical to be on the
> safe so you can take a closer look.
> I believe there is a significant possibility that not checking the nonce
> makes current Apache Kafka installations that use SCRAM susceptible to replay
> attacks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
