Cherrypick hardening DSA param checks from BoringSSL #2293
Merged
Conversation
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
This change was prompted by CVE-2024-4603, but is *not* part of it. BoringSSL is not affected by CVE-2024-4603. When applications use DSA they are expected to use known-valid domain parameters (as required by FIPS 186-4, section 4.3). If the application instead allows the attacker to supply domain parameters, DSA is no longer cryptographically sound, and algorithms that were otherwise correct now become DoS attack surfaces. Alas, incorrect uses of DSA, like Diffie-Hellman (see CVE-2023-3446 and CVE-2023-3817) are rampant, so it is useful to bound our operations, so we at least can say something coherent about DoS in this scenario, even though we cannot avoid the application being cryptographically unsound. To that end, we already check DSA sizes before using the key, however, we missed a couple of operations: - DSA_generate_parameters_ex - DSA_generate_key The CL adds those too. I would not expect either to have any security impact as it's quite unlikely for an application to allow attacker control of the inputs to either function. Still, we ought to check for completeness' sake. There's no sense in generating parameters or a key that we know we'll reject. Ultimately, the problem here is that DSA was a badly-designed primitive. with a continuum of domain parameters. Experience has shown that such systems are confusing and applications will often incorrectly treat domain parameters as part of the key. Modern primitives use a small set of discrete, named parameter sets, which is far easier to get right. For this reason, we consider DSA a deprecated, legacy algorithm. Change-Id: Ib3b5dece32bcb0ac9a795f8222c1c530d9dd91a0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68707 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: Adam Langley <[email protected]> Auto-Submit: David Benjamin <[email protected]>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2293 +/- ##
==========================================
- Coverage 79.04% 79.03% -0.02%
==========================================
Files 614 614
Lines 107058 107073 +15
Branches 15162 15164 +2
==========================================
- Hits 84627 84625 -2
- Misses 21778 21796 +18
+ Partials 653 652 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
skmcgrail
approved these changes
Mar 28, 2025
andrewhop
reviewed
Mar 28, 2025
| CRYPTO_EX_DATA ex_data; | ||
| }; | ||
|
|
||
| #define OPENSSL_DSA_MAX_MODULUS_BITS 10000 |
Contributor
There was a problem hiding this comment.
Can this go in a public header file so the DSA generate comment can say something like "only supports generating up to |OPENSSL_DSA_MAX_MODULUS_BITS| bit keys"?
justsmth
approved these changes
Mar 28, 2025
m271828
approved these changes
Mar 28, 2025
Merged
skmcgrail
added a commit
that referenced
this pull request
Mar 28, 2025
## What's Changed * Revert "Allow constructed strings in BER parsing (#2015)" by @samuel40791765 in #2278 * Add the rehash utility to the openssl CLI tool by @smittals2 in #2258 * Documentation on service indicator by @justsmth in #2281 * Update patches in Ruby CI by @samuel40791765 in #2233 * Reject DSA trailing garbage in EVP layer, add test cases by @skmcgrail in #2289 * Add support for verifying PKCS7 signed attributes by @samuel40791765 in #2264 * Add support for more SSL BIO functions by @samuel40791765 in #2273 * Wire-up rust-openssl into GitHub CI (for the time being) by @skmcgrail in #2291 * Adding detection of out-of-bound pre-bound memory read to AES-XTS tests. by @nebeid in #2286 * AES: Add function pointer trampoline to avoid delocator issue by @hanno-becker in #2294 * Bump mysql CI to 9.2.0 by @samuel40791765 in #2161 * Cherrypick hardening DSA param checks from BoringSSL by @smittals2 in #2293 By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 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.
Issues:
P211191334Description of changes:
This PR cherrypicks 68c29a24ee6c9c70ecce56766ca70b115aad768f from BoringSSL.
This change adds size checks to DSA_generate_parameters_ex and DSA_generate_key operations, completing our bounds checks for DSA operations. While this was prompted by CVE-2024-4603, BoringSSL and AWS-LC are not affected by that vulnerability. These additional checks likely have no security impact since attackers typically can't control inputs to these functions, but we're adding them for consistency with our other DSA operations.
Call-outs:
Point out areas that need special attention or support during the review process. Discuss architecture or design changes.
Testing:
How is this change tested (unit tests, fuzz tests, etc.)? Are there any testing steps to be verified by the reviewer?
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.