-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Attempt to mitigate Bleichenbacher attacks on RSA decryption (#5507)
- Loading branch information
Showing
3 changed files
with
18 additions
and
15 deletions.
There are no files selected for viewing
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -7,6 +7,7 @@ backend | |
Backends | ||
backends | ||
bcrypt | ||
Bleichenbacher | ||
Blowfish | ||
boolean | ||
Botan | ||
|
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
58494b4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi,
I'm trying to backporting that fix for an version 1.2.3 , in particular because it has that _098 function. I was wondering if it is needed to patch it in order to have a proper backport/fix. I understand you folks don't support old versions and so, but any tips, clues in how to proceed here would be very appreciated.
Thanks in advance
`def _enc_dec_rsa_098(backend, key, data, padding_enum):
if isinstance(key, _RSAPublicKey):
┆ crypt = backend._lib.RSA_public_encrypt
else:
┆ crypt = backend._lib.RSA_private_decrypt
58494b4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You probably want to make similar changes to both the 098 and pkey paths.
58494b4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, it makes sense. I'll try this. Thanks a bunch!
58494b4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything from this line onwards is written with the goal of being as
# constant-time as is practical given the constraints of Python and our
# API. See Bleichenbacher's '98 attack on RSA, and its many many variants.
# As such, you should not attempt to change this (particularly to "clean it
# up") without understanding why it was written this way (see
# Chesterton's Fence), and without measuring to verify you have not
# introduced observable time differences.
res = crypt(pkey_ctx, buf, outlen, data, len(data)) res = crypt(pkey_ctx, buf, outlen, data, len(data))
resbuf = backend._ffi.buffer(buf)[: outlen[0]]
backend._lib.ERR_clear_error()
if res <= 0: if res <= 0:
_handle_rsa_enc_dec_error(backend, key) raise ValueError("Encryption/decryption failed.")
58494b4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Patch security cryptograph
58494b4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Patch security cryptograph
58494b4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this still being worked on / maintained?
3.4.7 still reports a high severity vuln.
58494b4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whatever is notifying you is inaccurate. We shipped this in version 3.2.
58494b4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure we can just assume it's inaccurate. It's reported that reverting to 3.2 also opens up another Medium severity vuln. Will there be version released later than 3.4.7 with the fix?
58494b4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your data source is wrong, this issue has been fixed in all versions since 3.2.
58494b4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will there be version released later than 3.4.7 with the fix?
58494b4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don’t understand what you’re trying to say. Literally every version since 3.2 has had it. All versions past 3.4.7 (which also has it) will, of course, have it.
58494b4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it was reported by SNYK here https://snyk.io/vuln/SNYK-PYTHON-CRYPTOGRAPHY-1022152
58494b4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks @alevikpes yep this is where it's being reported.
so as far we snyk sees, it's not fixed in 3.4.7
58494b4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Calling this an incomplete fix which won't fly on our end and for probably most people.
58494b4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fix is incomplete because removing 100% of the timing differential requires a different API. (This is also only relevant if you're using these APIs in a fashion where they could be oracular.)
Ultimately this is a volunteer run project and no one has stepped up to provide that API. The tragedy here is that if/when we provide that constant-time API the vast, vast majority of callers won't migrate to it, but these scanners will proclaim it "fixed" since they only care about what version you're using, not the actual methods or the manner in which they're used.
For those who need this for genuine security reasons (e.g. implementation of online verification for a protocol, etc), please feel free to propose an API. #6167 is probably the right place to discuss it! We'd love to see this get done, but this thread is not the correct path.
I am locking this, but if people are interested in designing and implementing a constant-time variant API #6167 awaits. 😄
Edit: I have been told that there exist some Python scanners that detect API use. So the above is inaccurate, but the overall point remains since no static analyzer can determine the safety of the use of the "old" API. Marking all uses of it as vulnerable is incorrect, but also the best automation can do...