@hu-zongtang ,@jas0n918 ,@dingwei-hello ,@sundapeng001 ,@shilinlu
issue处理注意事项:
1. 当前issue受影响的分支提交pr时, 须在pr描述中填写当前issue编号进行关联, 否则无法关闭当前issue;
2. 模板内容需要填写完整, 无论是受影响或者不受影响都需要填写完整内容,未引入的分支不需要填写, 否则无法关闭当前issue;
3. 以下为模板中需要填写完整的内容, 请复制到评论区回复, 注: 内容的标题名称(影响性分析说明, openEuler评分, 受影响版本排查(受影响/不受影响), 修复是否涉及abi变化(是/否), 原因说明)不能省略,省略后cve-manager将无法正常解析填写内容.
影响性分析说明:
openEuler评分: (评分和向量)
受影响版本排查(受影响/不受影响):
1.master(2.8.2):
2.openEuler-20.03-LTS-SP4(2.8.2):
3.openEuler-22.03-LTS-SP1(2.8.2):
4.openEuler-22.03-LTS-SP3(2.8.2):
5.openEuler-22.03-LTS-SP4(2.8.2):
6.openEuler-24.03-LTS(2.8.2):
7.openEuler-24.03-LTS-Next(2.8.2):
8.openEuler-24.03-LTS-SP1(2.8.2):
修复是否涉及abi变化(是/否)：
1.master(2.8.2):
2.openEuler-20.03-LTS-SP4(2.8.2):
3.openEuler-22.03-LTS-SP1(2.8.2):
4.openEuler-22.03-LTS-SP3(2.8.2):
5.openEuler-22.03-LTS-SP4(2.8.2):
6.openEuler-24.03-LTS(2.8.2):
7.openEuler-24.03-LTS-Next(2.8.2):
8.openEuler-24.03-LTS-SP1(2.8.2):
原因说明：
1.master(2.8.2):
2.openEuler-20.03-LTS-SP4(2.8.2):
3.openEuler-22.03-LTS-SP1(2.8.2):
4.openEuler-22.03-LTS-SP3(2.8.2):
5.openEuler-22.03-LTS-SP4(2.8.2):
6.openEuler-24.03-LTS(2.8.2):
7.openEuler-24.03-LTS-Next(2.8.2):
8.openEuler-24.03-LTS-SP1(2.8.2):
原因说明填写请参考下方表格(注意：版本是否受影响和版本的原因说明必须对应，例如master版本分支受影响，那原因说明只能是受影响对应的原因之一!)：
| 分支状态 | 原因说明 |
|---|---|
| 受影响 | 正常修复 |
| 受影响 | 暂不修复-漏洞仍在分析中 |
| 受影响 | 暂不修复-暂无解决方案或补丁 |
| 受影响 | 暂不修复-待升级版本修复 |
| 受影响 | 不修复-超出修复范围 |
| 受影响 | 不修复-特殊原因导致不再修复 |
| 不受影响 | 不受影响-组件不存在 |
| 不受影响 | 不受影响-已有内置的内联控制或缓解措施 |
| 不受影响 | 不受影响-漏洞代码不能被攻击者触发 |
| 不受影响 | 不受影响-漏洞代码不在执行路径 |
| 不受影响 | 不受影响-漏洞代码不存在 |
issue处理具体操作请参考:
https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
pr关联issue具体操作请参考:
https://gitee.com/help/articles/4142
Hi openeuler-ci-bot, welcome to the openEuler Community.
I'm the Bot here serving you. You can find the instructions on how to interact with me at Here.
If you have any questions, please contact the SIG: sig-message-middleware, and any of the maintainers: @hu-zongtang , @jas0n918 , @dingwei-hello , any of the committers: @shilinlu , @dingwei-hello , @sundapeng001
yanzhicong1影响性分析说明:
openEuler评分: (评分和向量)
经过cve-manager解析，部分字段填写错误，如红色字体所示：
影响性分析说明:
(请填写此字段)
openEuler评分: (评分和向量)
5.3
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
受影响版本排查(受影响/不受影响):
1.master:(请填写此字段)
2.openEuler-20.03-LTS-SP4:(请填写此字段)
3.openEuler-22.03-LTS-SP1:(请填写此字段)
4.openEuler-22.03-LTS-SP3:(请填写此字段)
5.openEuler-22.03-LTS-SP4:(请填写此字段)
6.openEuler-24.03-LTS:(请填写此字段)
7.openEuler-24.03-LTS-Next:(请填写此字段)
8.openEuler-24.03-LTS-SP1:(请填写此字段)
9.openEuler-24.03-LTS-SP3:(请填写此字段)
10.openEuler-24.03-LTS-SP4:(请填写此字段)
修复是否涉及abi变化(是/否)：
1.master:(请填写此字段)
2.openEuler-20.03-LTS-SP4:(请填写此字段)
3.openEuler-22.03-LTS-SP1:(请填写此字段)
4.openEuler-22.03-LTS-SP3:(请填写此字段)
5.openEuler-22.03-LTS-SP4:(请填写此字段)
6.openEuler-24.03-LTS:(请填写此字段)
7.openEuler-24.03-LTS-Next:(请填写此字段)
8.openEuler-24.03-LTS-SP1:(请填写此字段)
9.openEuler-24.03-LTS-SP3:(请填写此字段)
10.openEuler-24.03-LTS-SP4:(请填写此字段)
原因说明：
1.master:(请填写此字段)
2.openEuler-20.03-LTS-SP4:(请填写此字段)
3.openEuler-22.03-LTS-SP1:(请填写此字段)
4.openEuler-22.03-LTS-SP3:(请填写此字段)
5.openEuler-22.03-LTS-SP4:(请填写此字段)
6.openEuler-24.03-LTS:(请填写此字段)
7.openEuler-24.03-LTS-Next:(请填写此字段)
8.openEuler-24.03-LTS-SP1:(请填写此字段)
9.openEuler-24.03-LTS-SP3:(请填写此字段)
10.openEuler-24.03-LTS-SP4:(请填写此字段)
影响性分析说明:
Incorrect Implementation of Authentication Algorithm in Apache Kafka s SCRAM implementation.Issue Summary:Apache Kafka s implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1].Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message.However, Kafka s SCRAM implementation did not perform this validation.Impact:This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is stronglydiscouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3].Deployments using SCRAM with TLS are not affected by this issue.How to Detect If You Are Impacted:If your deployment uses SCRAM authentication over plaintext communication channels (without TLS encryption), you are likely impacted.To check if TLS is enabled, review your server.properties configuration file for listeners property. If you have SASL_PLAINTEXT in the listeners, then you are likely impacted.Fix Details:The issue has been addressed by introducing nonce verification in the final message of the SCRAM authentication exchange to ensure compliance with RFC 5802.Affected Versions:Apache Kafka versions 0.10.2.0 through 3.9.0, excluding the fixed versions below.Fixed Versions:3.9.03.8.13.7.2Users are advised to upgrade to 3.7.2 or later to mitigate this issue.Recommendations for Mitigation:Users unable to upgrade to the fixed versions can mitigate the issue by:- Using TLS with SCRAM Authentication:Always deploy SCRAM over TLS to encrypt authentication exchanges and protect against interception.- Considering Alternative Authentication Mechanisms:Evaluate alternative authentication mechanisms, such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security.
openEuler评分: (评分和向量)
BaseScore：5.3 Medium
Vector：CVSS：3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
受影响版本排查(受影响/不受影响):
1.master:受影响
2.openEuler-20.03-LTS-SP4:受影响
3.openEuler-22.03-LTS-SP1:受影响
4.openEuler-22.03-LTS-SP3:受影响
5.openEuler-22.03-LTS-SP4:受影响
6.openEuler-24.03-LTS:受影响
7.openEuler-24.03-LTS-Next:受影响
8.openEuler-24.03-LTS-SP1:受影响
9.openEuler-24.03-LTS-SP3:受影响
10.openEuler-24.03-LTS-SP4:受影响
修复是否涉及abi变化(是/否)：
1.master:否
2.openEuler-20.03-LTS-SP4:否
3.openEuler-22.03-LTS-SP1:否
4.openEuler-22.03-LTS-SP3:否
5.openEuler-22.03-LTS-SP4:否
6.openEuler-24.03-LTS:否
7.openEuler-24.03-LTS-Next:否
8.openEuler-24.03-LTS-SP1:否
9.openEuler-24.03-LTS-SP3:否
10.openEuler-24.03-LTS-SP4:否
原因说明：
1.master:正常修复
2.openEuler-20.03-LTS-SP4:正常修复
3.openEuler-22.03-LTS-SP1:不修复-超出修复范围
4.openEuler-22.03-LTS-SP3:不修复-超出修复范围
5.openEuler-22.03-LTS-SP4:正常修复
6.openEuler-24.03-LTS:不修复-超出修复范围
7.openEuler-24.03-LTS-Next:正常修复
8.openEuler-24.03-LTS-SP1:正常修复
9.openEuler-24.03-LTS-SP3:正常修复
10.openEuler-24.03-LTS-SP4:正常修复
@ 经过 cve-manager 解析, 已分析的内容如下表所示:
| 状态 | 分析项目 | 内容 |
|---|---|---|
| 已分析 | 1.影响性分析说明 | Incorrect Implementation of Authentication Algorithm in Apache Kafka s SCRAM implementation.Issue Summary:Apache Kafka s implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1].Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message.However, Kafka s SCRAM implementation did not perform this validation.Impact:This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is stronglydiscouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3].Deployments using SCRAM with TLS are not affected by this issue.How to Detect If You Are Impacted:If your deployment uses SCRAM authentication over plaintext communication channels (without TLS encryption), you are likely impacted.To check if TLS is enabled, review your server.properties configuration file for listeners property. If you have SASL_PLAINTEXT in the listeners, then you are likely impacted.Fix Details:The issue has been addressed by introducing nonce verification in the final message of the SCRAM authentication exchange to ensure compliance with RFC 5802.Affected Versions:Apache Kafka versions 0.10.2.0 through 3.9.0, excluding the fixed versions below.Fixed Versions:3.9.03.8.13.7.2Users are advised to upgrade to 3.7.2 or later to mitigate this issue.Recommendations for Mitigation:Users unable to upgrade to the fixed versions can mitigate the issue by:- Using TLS with SCRAM Authentication:Always deploy SCRAM over TLS to encrypt authentication exchanges and protect against interception.- Considering Alternative Authentication Mechanisms:Evaluate alternative authentication mechanisms, such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security. |
| 已分析 | 2.openEulerScore | 5.3 |
| 已分析 | 3.openEulerVector | AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N |
| 已分析 | 4.受影响版本排查 | master:受影响,openEuler-20.03-LTS-SP4:受影响,openEuler-22.03-LTS-SP1:受影响,openEuler-22.03-LTS-SP3:受影响,openEuler-22.03-LTS-SP4:受影响,openEuler-24.03-LTS:受影响,openEuler-24.03-LTS-Next:受影响,openEuler-24.03-LTS-SP1:受影响,openEuler-24.03-LTS-SP3:受影响,openEuler-24.03-LTS-SP4:受影响 |
| 已分析 | 5.是否涉及abi变化 | master:否,openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP1:否,openEuler-22.03-LTS-SP3:否,openEuler-22.03-LTS-SP4:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-Next:否,openEuler-24.03-LTS-SP1:否,openEuler-24.03-LTS-SP3:否,openEuler-24.03-LTS-SP4:否 |
| 已分析 | 6.原因说明 | master:正常修复,openEuler-20.03-LTS-SP4:正常修复,openEuler-22.03-LTS-SP1:不修复-超出修复范围,openEuler-22.03-LTS-SP3:不修复-超出修复范围,openEuler-22.03-LTS-SP4:正常修复,openEuler-24.03-LTS:不修复-超出修复范围,openEuler-24.03-LTS-Next:正常修复,openEuler-24.03-LTS-SP1:正常修复,openEuler-24.03-LTS-SP3:正常修复,openEuler-24.03-LTS-SP4:正常修复 |
请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.
经过cve-manager解析，部分分支PR未合入，如红色字体所示：
原因说明：
1.master:正常修复(PR未合入)
2.openEuler-20.03-LTS-SP4:正常修复(PR未合入)
3.openEuler-22.03-LTS-SP1:不修复-超出修复范围
4.openEuler-22.03-LTS-SP3:不修复-超出修复范围
5.openEuler-22.03-LTS-SP4:正常修复(PR未合入)
6.openEuler-24.03-LTS:不修复-超出修复范围
7.openEuler-24.03-LTS-Next:正常修复(PR未合入)
8.openEuler-24.03-LTS-SP1:正常修复(PR未合入)
9.openEuler-24.03-LTS-SP3:正常修复(PR未合入)
10.openEuler-24.03-LTS-SP4:正常修复(PR未合入)
openeuler-ci-bot
影响性分析说明:
Incorrect Implementation of Authentication Algorithm in Apache Kafka s SCRAM implementation.Issue Summary:Apache Kafka s implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1].Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message.However, Kafka s SCRAM implementation did not perform this validation.Impact:This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is stronglydiscouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3].Deployments using SCRAM with TLS are not affected by this issue.How to Detect If You Are Impacted:If your deployment uses SCRAM authentication over plaintext communication channels (without TLS encryption), you are likely impacted.To check if TLS is enabled, review your server.properties configuration file for listeners property. If you have SASL_PLAINTEXT in the listeners, then you are likely impacted.Fix Details:The issue has been addressed by introducing nonce verification in the final message of the SCRAM authentication exchange to ensure compliance with RFC 5802.Affected Versions:Apache Kafka versions 0.10.2.0 through 3.9.0, excluding the fixed versions below.Fixed Versions:3.9.03.8.13.7.2Users are advised to upgrade to 3.7.2 or later to mitigate this issue.Recommendations for Mitigation:Users unable to upgrade to the fixed versions can mitigate the issue by:- Using TLS with SCRAM Authentication:Always deploy SCRAM over TLS to encrypt authentication exchanges and protect against interception.- Considering Alternative Authentication Mechanisms:Evaluate alternative authentication mechanisms, such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security.
openEuler评分: (评分和向量)
BaseScore：5.3 Medium
Vector：CVSS：3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
受影响版本排查(受影响/不受影响):
1.master:受影响
2.openEuler-20.03-LTS-SP4:受影响
3.openEuler-22.03-LTS-SP1:受影响
4.openEuler-22.03-LTS-SP3:受影响
5.openEuler-22.03-LTS-SP4:受影响
6.openEuler-24.03-LTS:受影响
7.openEuler-24.03-LTS-Next:受影响
8.openEuler-24.03-LTS-SP1:受影响
9.openEuler-24.03-LTS-SP3:受影响
10.openEuler-24.03-LTS-SP4:受影响
修复是否涉及abi变化(是/否)：
1.master:否
2.openEuler-20.03-LTS-SP4:否
3.openEuler-22.03-LTS-SP1:否
4.openEuler-22.03-LTS-SP3:否
5.openEuler-22.03-LTS-SP4:否
6.openEuler-24.03-LTS:否
7.openEuler-24.03-LTS-Next:否
8.openEuler-24.03-LTS-SP1:否
9.openEuler-24.03-LTS-SP3:否
10.openEuler-24.03-LTS-SP4:否
原因说明：
1.master:正常修复
2.openEuler-20.03-LTS-SP4:正常修复
3.openEuler-22.03-LTS-SP1:不修复-超出修复范围
4.openEuler-22.03-LTS-SP3:不修复-超出修复范围
5.openEuler-22.03-LTS-SP4:正常修复
6.openEuler-24.03-LTS:不修复-超出修复范围
7.openEuler-24.03-LTS-Next:正常修复
8.openEuler-24.03-LTS-SP1:正常修复
9.openEuler-24.03-LTS-SP3:正常修复
10.openEuler-24.03-LTS-SP4:正常修复
@ 经过 cve-manager 解析, 已分析的内容如下表所示:
| 状态 | 分析项目 | 内容 |
|---|---|---|
| 已分析 | 1.影响性分析说明 | Incorrect Implementation of Authentication Algorithm in Apache Kafka s SCRAM implementation.Issue Summary:Apache Kafka s implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1].Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message.However, Kafka s SCRAM implementation did not perform this validation.Impact:This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is stronglydiscouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3].Deployments using SCRAM with TLS are not affected by this issue.How to Detect If You Are Impacted:If your deployment uses SCRAM authentication over plaintext communication channels (without TLS encryption), you are likely impacted.To check if TLS is enabled, review your server.properties configuration file for listeners property. If you have SASL_PLAINTEXT in the listeners, then you are likely impacted.Fix Details:The issue has been addressed by introducing nonce verification in the final message of the SCRAM authentication exchange to ensure compliance with RFC 5802.Affected Versions:Apache Kafka versions 0.10.2.0 through 3.9.0, excluding the fixed versions below.Fixed Versions:3.9.03.8.13.7.2Users are advised to upgrade to 3.7.2 or later to mitigate this issue.Recommendations for Mitigation:Users unable to upgrade to the fixed versions can mitigate the issue by:- Using TLS with SCRAM Authentication:Always deploy SCRAM over TLS to encrypt authentication exchanges and protect against interception.- Considering Alternative Authentication Mechanisms:Evaluate alternative authentication mechanisms, such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security. |
| 已分析 | 2.openEulerScore | 5.3 |
| 已分析 | 3.openEulerVector | AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N |
| 已分析 | 4.受影响版本排查 | master:受影响,openEuler-20.03-LTS-SP4:受影响,openEuler-22.03-LTS-SP1:受影响,openEuler-22.03-LTS-SP3:受影响,openEuler-22.03-LTS-SP4:受影响,openEuler-24.03-LTS:受影响,openEuler-24.03-LTS-Next:受影响,openEuler-24.03-LTS-SP1:受影响,openEuler-24.03-LTS-SP3:受影响,openEuler-24.03-LTS-SP4:受影响 |
| 已分析 | 5.是否涉及abi变化 | master:否,openEuler-20.03-LTS-SP4:否,openEuler-22.03-LTS-SP1:否,openEuler-22.03-LTS-SP3:否,openEuler-22.03-LTS-SP4:否,openEuler-24.03-LTS:否,openEuler-24.03-LTS-Next:否,openEuler-24.03-LTS-SP1:否,openEuler-24.03-LTS-SP3:否,openEuler-24.03-LTS-SP4:否 |
| 已分析 | 6.原因说明 | master:正常修复,openEuler-20.03-LTS-SP4:正常修复,openEuler-22.03-LTS-SP1:不修复-超出修复范围,openEuler-22.03-LTS-SP3:不修复-超出修复范围,openEuler-22.03-LTS-SP4:正常修复,openEuler-24.03-LTS:不修复-超出修复范围,openEuler-24.03-LTS-Next:正常修复,openEuler-24.03-LTS-SP1:正常修复,openEuler-24.03-LTS-SP3:正常修复,openEuler-24.03-LTS-SP4:正常修复 |
请确认分析内容的准确性, 确认无误后, 您可以进行后续步骤, 否则您可以继续分析.
经过cve-manager解析，(所有PR均已合入)
经过cve-manager解析，(所有PR均已合入)
一、漏洞信息
漏洞编号：CVE-2024-56128
漏洞归属组件：kafka
漏洞归属的版本：2.4.0,2.8.1,2.8.2
CVSS评分：
BaseScore：5.3 Medium
Vector：CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
漏洞简述：
Incorrect Implementation of Authentication Algorithm in Apache Kafka s SCRAM implementation.Issue Summary:Apache Kafka s implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1].Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message.However, Kafka s SCRAM implementation did not perform this validation.Impact:This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is stronglydiscouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3].Deployments using SCRAM with TLS are not affected by this issue.How to Detect If You Are Impacted:If your deployment uses SCRAM authentication over plaintext communication channels (without TLS encryption), you are likely impacted.To check if TLS is enabled, review your server.properties configuration file for listeners property. If you have SASL_PLAINTEXT in the listeners, then you are likely impacted.Fix Details:The issue has been addressed by introducing nonce verification in the final message of the SCRAM authentication exchange to ensure compliance with RFC 5802.Affected Versions:Apache Kafka versions 0.10.2.0 through 3.9.0, excluding the fixed versions below.Fixed Versions:3.9.03.8.13.7.2Users are advised to upgrade to 3.7.2 or later to mitigate this issue.Recommendations for Mitigation:Users unable to upgrade to the fixed versions can mitigate the issue by:- Using TLS with SCRAM Authentication:Always deploy SCRAM over TLS to encrypt authentication exchanges and protect against interception.- Considering Alternative Authentication Mechanisms:Evaluate alternative authentication mechanisms, such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security.
漏洞公开时间：2024-12-18 22:15:23
漏洞创建时间：2024-12-18 22:20:23
漏洞详情参考链接：
https://nvd.nist.gov/vuln/detail/CVE-2024-56128
更多参考(点击展开)
漏洞分析指导链接：
https://atomgit.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
漏洞数据来源:
openBrain开源漏洞感知系统
漏洞补丁信息：
详情(点击展开)
无
二、漏洞分析结构反馈
影响性分析说明：
Incorrect Implementation of Authentication Algorithm in Apache Kafka s SCRAM implementation.Issue Summary:Apache Kafka s implementation of the Salted Challenge Response Authentication Mechanism (SCRAM) did not fully adhere to the requirements of RFC 5802 [1].Specifically, as per RFC 5802, the server must verify that the nonce sent by the client in the second message matches the nonce sent by the server in its first message.However, Kafka s SCRAM implementation did not perform this validation.Impact:This vulnerability is exploitable only when an attacker has plaintext access to the SCRAM authentication exchange. However, the usage of SCRAM over plaintext is stronglydiscouraged as it is considered an insecure practice [2]. Apache Kafka recommends deploying SCRAM exclusively with TLS encryption to protect SCRAM exchanges from interception [3].Deployments using SCRAM with TLS are not affected by this issue.How to Detect If You Are Impacted:If your deployment uses SCRAM authentication over plaintext communication channels (without TLS encryption), you are likely impacted.To check if TLS is enabled, review your server.properties configuration file for listeners property. If you have SASL_PLAINTEXT in the listeners, then you are likely impacted.Fix Details:The issue has been addressed by introducing nonce verification in the final message of the SCRAM authentication exchange to ensure compliance with RFC 5802.Affected Versions:Apache Kafka versions 0.10.2.0 through 3.9.0, excluding the fixed versions below.Fixed Versions:3.9.03.8.13.7.2Users are advised to upgrade to 3.7.2 or later to mitigate this issue.Recommendations for Mitigation:Users unable to upgrade to the fixed versions can mitigate the issue by:- Using TLS with SCRAM Authentication:Always deploy SCRAM over TLS to encrypt authentication exchanges and protect against interception.- Considering Alternative Authentication Mechanisms:Evaluate alternative authentication mechanisms, such as PLAIN, Kerberos or OAuth with TLS, which provide additional layers of security.
openEuler评分：
5.3
Vector：CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
受影响版本排查(受影响/不受影响)：
1.master(2.8.2):受影响
2.openEuler-20.03-LTS-SP4(2.8.2):受影响
3.openEuler-22.03-LTS-SP1(2.8.2):受影响
4.openEuler-22.03-LTS-SP3(2.8.2):受影响
5.openEuler-22.03-LTS-SP4(2.8.2):受影响
6.openEuler-24.03-LTS(2.8.2):受影响
7.openEuler-24.03-LTS-Next(2.8.2):受影响
8.openEuler-24.03-LTS-SP1(2.8.2):受影响
9.openEuler-24.03-LTS-SP3(2.8.2):受影响
10.openEuler-24.03-LTS-SP4(2.8.2):受影响
修复是否涉及abi变化(是/否)：
1.master(2.8.2):否
2.openEuler-20.03-LTS-SP4(2.8.2):否
3.openEuler-22.03-LTS-SP1(2.8.2):否
4.openEuler-22.03-LTS-SP3(2.8.2):否
5.openEuler-22.03-LTS-SP4(2.8.2):否
6.openEuler-24.03-LTS(2.8.2):否
7.openEuler-24.03-LTS-Next(2.8.2):否
8.openEuler-24.03-LTS-SP1(2.8.2):否
9.openEuler-24.03-LTS-SP3(2.8.2):否
10.openEuler-24.03-LTS-SP4(2.8.2):否
原因说明：
1.master(2.8.2):正常修复
2.openEuler-20.03-LTS-SP4(2.8.2):正常修复
3.openEuler-22.03-LTS-SP1(2.8.2):不修复-超出修复范围
4.openEuler-22.03-LTS-SP3(2.8.2):不修复-超出修复范围
5.openEuler-22.03-LTS-SP4(2.8.2):正常修复
6.openEuler-24.03-LTS(2.8.2):不修复-超出修复范围
7.openEuler-24.03-LTS-Next(2.8.2):正常修复
8.openEuler-24.03-LTS-SP1(2.8.2):正常修复
9.openEuler-24.03-LTS-SP3(2.8.2):正常修复
10.openEuler-24.03-LTS-SP4(2.8.2):正常修复