Fix a padding oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey#9777
Closed
bernd-edlinger wants to merge 3 commits intoopenssl:masterfrom
Closed
Fix a padding oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey#9777bernd-edlinger wants to merge 3 commits intoopenssl:masterfrom
bernd-edlinger wants to merge 3 commits intoopenssl:masterfrom
Conversation
bernd-edlinger
added
branch: master
An attack is simple, if the first CMS_recipientInfo is valid but the second CMS_recipientInfo is chosen ciphertext. If the second recipientInfo decodes to PKCS openssl#1 v1.5 form plaintext, the correct encryption key will be replaced by garbage, and the message cannot be decoded, but if the RSA decryption fails, the correct encryption key is used and the recipient will not notice the attack. As a work around for this potential attack the length of the decrypted key must be equal to the cipher default key length, in case the certifiate is not given and all recipientInfo are tried out. The old behaviour can be re-enabled in the CMS code by setting the CMS_DEBUG_DECRYPT flag.
bernd-edlinger
force-pushed
the
fix_padding_oracle_in_pkcs_and_cms_decrypt
branch
from
e15f268 to
b19cf10
Compare
Member
Author
|
Re-based to resolve merge conflict in CHANGES |
Member
Author
|
Something for tomorrow? |
mattcaswell
requested changes
Sep 9, 2019
Member
|
Darn. I forgot to merge this one before the other CHANGES/NEWS updates went in - which now cause merge conflicts in CHANGES. I intend to resolve those conflicts manually by replacing the existing text about this issue with the CHANGES entry in this PR (but keeping the CVE number) |
mattcaswell
approved these changes
Sep 10, 2019
levitte
pushed a commit
that referenced
this pull request
Sep 10, 2019
An attack is simple, if the first CMS_recipientInfo is valid but the second CMS_recipientInfo is chosen ciphertext. If the second recipientInfo decodes to PKCS #1 v1.5 form plaintext, the correct encryption key will be replaced by garbage, and the message cannot be decoded, but if the RSA decryption fails, the correct encryption key is used and the recipient will not notice the attack. As a work around for this potential attack the length of the decrypted key must be equal to the cipher default key length, in case the certifiate is not given and all recipientInfo are tried out. The old behaviour can be re-enabled in the CMS code by setting the CMS_DEBUG_DECRYPT flag. Reviewed-by: Matt Caswell <[email protected]> (Merged from #9777)
levitte
pushed a commit
that referenced
this pull request
Sep 10, 2019
An attack is simple, if the first CMS_recipientInfo is valid but the second CMS_recipientInfo is chosen ciphertext. If the second recipientInfo decodes to PKCS #1 v1.5 form plaintext, the correct encryption key will be replaced by garbage, and the message cannot be decoded, but if the RSA decryption fails, the correct encryption key is used and the recipient will not notice the attack. As a work around for this potential attack the length of the decrypted key must be equal to the cipher default key length, in case the certifiate is not given and all recipientInfo are tried out. The old behaviour can be re-enabled in the CMS code by setting the CMS_DEBUG_DECRYPT flag. Reviewed-by: Matt Caswell <[email protected]> (Merged from #9777) (cherry picked from commit 5840ed0)
levitte
pushed a commit
that referenced
this pull request
Sep 10, 2019
An attack is simple, if the first CMS_recipientInfo is valid but the second CMS_recipientInfo is chosen ciphertext. If the second recipientInfo decodes to PKCS #1 v1.5 form plaintext, the correct encryption key will be replaced by garbage, and the message cannot be decoded, but if the RSA decryption fails, the correct encryption key is used and the recipient will not notice the attack. As a work around for this potential attack the length of the decrypted key must be equal to the cipher default key length, in case the certifiate is not given and all recipientInfo are tried out. The old behaviour can be re-enabled in the CMS code by setting the CMS_DEBUG_DECRYPT flag. Reviewed-by: Matt Caswell <[email protected]> (Merged from #9777) (cherry picked from commit 5840ed0)
levitte
pushed a commit
that referenced
this pull request
Sep 10, 2019
An attack is simple, if the first CMS_recipientInfo is valid but the second CMS_recipientInfo is chosen ciphertext. If the second recipientInfo decodes to PKCS #1 v1.5 form plaintext, the correct encryption key will be replaced by garbage, and the message cannot be decoded, but if the RSA decryption fails, the correct encryption key is used and the recipient will not notice the attack. As a work around for this potential attack the length of the decrypted key must be equal to the cipher default key length, in case the certifiate is not given and all recipientInfo are tried out. The old behaviour can be re-enabled in the CMS code by setting the CMS_DEBUG_DECRYPT flag. Reviewed-by: Matt Caswell <[email protected]> (Merged from #9777) (cherry picked from commit 5840ed0)
Member
In the end the conflicts that came up were trivial so I just fixed them. They resulted in duplicate CHANGES entries for this particular issue, and the resolution to that was beyond what I considered trivial - so I pushed "as is" and plan to fix up CHANGES in a subsequent PR. Pushed to master, 1.1.1, 1.1.0 and 1.0.2 |
bob-beck
pushed a commit
to openbsd/src
that referenced
this pull request
Oct 4, 2019
(Note that the CMS code is currently disabled.) Port of Edlinger's Fix for CVE-2019-1563 from OpenSSL 1.1.1 (old license) tests from bluhm@ ok jsing commit e21f8cf78a125cd3c8c0d1a1a6c8bb0b901f893f Author: Bernd Edlinger <[email protected]> Date: Sun Sep 1 00:16:28 2019 +0200 Fix a padding oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey An attack is simple, if the first CMS_recipientInfo is valid but the second CMS_recipientInfo is chosen ciphertext. If the second recipientInfo decodes to PKCS #1 v1.5 form plaintext, the correct encryption key will be replaced by garbage, and the message cannot be decoded, but if the RSA decryption fails, the correct encryption key is used and the recipient will not notice the attack. As a work around for this potential attack the length of the decrypted key must be equal to the cipher default key length, in case the certifiate is not given and all recipientInfo are tried out. The old behaviour can be re-enabled in the CMS code by setting the CMS_DEBUG_DECRYPT flag. Reviewed-by: Matt Caswell <[email protected]> (Merged from openssl/openssl#9777) (cherry picked from commit 5840ed0cd1e6487d247efbc1a04136a41d7b3a37)
busterb
pushed a commit
to libressl/openbsd
that referenced
this pull request
Oct 11, 2019
(Note that the CMS code is currently disabled.) Port of Edlinger's Fix for CVE-2019-1563 from OpenSSL 1.1.1 (old license) tests from bluhm@ ok jsing commit e21f8cf78a125cd3c8c0d1a1a6c8bb0b901f893f Author: Bernd Edlinger <[email protected]> Date: Sun Sep 1 00:16:28 2019 +0200 Fix a padding oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey An attack is simple, if the first CMS_recipientInfo is valid but the second CMS_recipientInfo is chosen ciphertext. If the second recipientInfo decodes to PKCS #1 v1.5 form plaintext, the correct encryption key will be replaced by garbage, and the message cannot be decoded, but if the RSA decryption fails, the correct encryption key is used and the recipient will not notice the attack. As a work around for this potential attack the length of the decrypted key must be equal to the cipher default key length, in case the certifiate is not given and all recipientInfo are tried out. The old behaviour can be re-enabled in the CMS code by setting the CMS_DEBUG_DECRYPT flag. Reviewed-by: Matt Caswell <[email protected]> (Merged from openssl/openssl#9777) (cherry picked from commit 5840ed0cd1e6487d247efbc1a04136a41d7b3a37)
vathpela
pushed a commit
to rhboot/openssl
that referenced
this pull request
Dec 10, 2019
An attack is simple, if the first CMS_recipientInfo is valid but the second CMS_recipientInfo is chosen ciphertext. If the second recipientInfo decodes to PKCS openssl#1 v1.5 form plaintext, the correct encryption key will be replaced by garbage, and the message cannot be decoded, but if the RSA decryption fails, the correct encryption key is used and the recipient will not notice the attack. As a work around for this potential attack the length of the decrypted key must be equal to the cipher default key length, in case the certifiate is not given and all recipientInfo are tried out. The old behaviour can be re-enabled in the CMS code by setting the CMS_DEBUG_DECRYPT flag. Reviewed-by: Matt Caswell <[email protected]> (Merged from openssl#9777) (cherry picked from commit 5840ed0)
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
An attack is simple, if the first CMS_recipientInfo is valid but the
second CMS_recipientInfo is chosen ciphertext. If the second
recipientInfo decodes to PKCS #1 v1.5 form plaintext, the correct
encryption key will be replaced by garbage, and the message cannot be
decoded, but if the RSA decryption fails, the correct encryption key is
used and the recipient will not notice the attack.
As a work around for this potential attack the length of the decrypted
key must be equal to the cipher default key length, in case the
certifiate is not given and all recipientInfo are tried out.
The old behaviour can be re-enabled in the CMS code by setting the
CMS_DEBUG_DECRYPT flag.
Checklist