Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some components use strcmp which is vulnerable to timing attacks #4639

Open
7 tasks done
HRsGIT opened this issue Mar 7, 2024 · 1 comment
Open
7 tasks done

Some components use strcmp which is vulnerable to timing attacks #4639

HRsGIT opened this issue Mar 7, 2024 · 1 comment

Comments

@HRsGIT
Copy link

HRsGIT commented Mar 7, 2024

Description

Some components in librdkafka use strcmp to validate a password, signature or key, which is vulnerable to timing attacks that make brute force attacks for such credentials more likely to be successful. For example, consider lines 842 and 567 in rdkafka_sasl_scram.c. A similar issue occurred with Apache Kafka, which has been assigned CVE-2021-38153.
Patch in Apache Kafka
image
Code in ibrdkafka
image

Checklist

IMPORTANT: We will close issues where the checklist has not been completed.

Please provide the following information:

  • librdkafka version (release number or git tag): [v2.3.0](https://github.com/confluentinc/librdkafka/releases/tag/v2.3.0)
  • Apache Kafka version: [3.7.0](https://github.com/apache/kafka/releases/tag/3.7.0)
  • librdkafka client configuration: no
  • Operating system: no
  • Provide logs (with debug=.. as necessary) from librdkafka
  • Provide broker log excerpts
  • Critical issue
@emasab
Copy link
Collaborator

emasab commented May 9, 2024

I think it's very difficult to find a timing based brute force attack to guess ServerSignatureB64 from this. Even if the connecting broker is a Mallory. because the ServerSignatureB64 is calculated from AuthMessage that contains the client salt, that it's random. So ServerSignatureB64 changes at every connection attempt. Connection attempts start from a backoff of 100ms and reach a maximum of 10s.

Given that, I don't know if some kind of cryptographical analysis can be applied on top of this, could you explain how an attack would look like. Not a generic timing attack but for this specific field?
The fix would be to compare all the bytes in the signature instead of stopping at first one that differs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants