Bug 2263326
Summary: | Side-channel in libjwt | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora EPEL | Reporter: | Erwan Legrand <redhat> | ||||
Component: | libjwt | Assignee: | Ward <wpoely86> | ||||
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | epel9 | CC: | jsmith.fedora, pkfed, wpoely86 | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2025-06-26 12:39:38 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Erwan Legrand
2024-02-08 11:59:55 UTC
Did you get any feedback from upstream? If there isn't a patch, I can't do much. Yes, I was able to reach the maintainer and he said he would release a patch. I had started contacting maintainers of packages in Linux distros because I couldn't find a way to contact him at first. Then I found a way but I opened this anyway. From upstream: As noted, the strcmp() function can be used for time-based side attacks. I tried to test this and could not find a reasonable way to implement this attack for several reasons: 1) strcmp() is optimized to compare 4 and 8 bytes at a time when possible on almost every modern system, making the attack almost impossible. 2) Running 128 million iterations of strcmp() for a single byte attack gave sub-nanosecond average differences (locally on same excution stack) and almost as often as the comparison was correct, it was also wrong in the reverse sense (i.e. two byte strcmp() took less time than single byte). 3) Adding noise from network, application stack, web server, etc. would only add to the failure rate of guessing the differences above. Erwan noted that there are proofs out there showing that signal noise reduction can make this guessing more "accurate", but this proof also noted it would take up to 4 billion guesses to completely cover this attack surface. The claim was that 50k attempts per second would break a 256-bit hmac in 22 hours. While this isn't impossible, it's very implausible. However, for the sake of cryptographic correctness, I implemented jwt_strcmp() which always compares all bytes, and does so up to the longest string in the 2-string set, without passing string boundaries. This makes it time-consistent for len(max(a,b)) comparisons. I proofed this using a 128 million interation average for various scenarious. I've created scratch build of libjwt 1.17.0. The biggest issue is that there is a soname change: the main library bumped from so.1 to so.2. I'm not sure what the proper procedure is on this? Pushing this to EPEL will break anything that uses it (like the Slurm job scheduler). Created attachment 2017561 [details]
Proposed patch
Patch against libjwt-0.12.1
Here is a patch against 0.12.1. I hope this helps. I'm going to close this. The issue is difficult to exploit according to the main developer. For el10 and newer Fedora, we have jumped to libjwt 2.x which is not impacted. |