-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
src: fix CSPRNG when length exceeds INT_MAX #47515
src: fix CSPRNG when length exceeds INT_MAX #47515
Conversation
CSPRNG implicitly casts the size_t length argument to a signed int when calling RAND_bytes(), which leaves it up to the caller to ensure that the length argument actually fits into such a signed int. However, not all call sites explicitly ensure that, which could lead to subtle bugs. In OpenSSL 3, use RAND_bytes_ex() instead, which does not require casting the length to a signed int. In OpenSSL 1.1.1, RAND_bytes_ex() is not supported, thus we have to process blocks of size INT_MAX one by one.
Review requested:
|
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 could live with just returning {false}
instead of complicating the code with a retry loop. There's simply no valid use case for requesting that much random data.
@bnoordhuis The added complexity only exists in the OpenSSL 1.1.1 section, which will be removed in about half a year. Until then, it ensures that the behavior is consistent across OpenSSL 3 / OpenSSL 1.1.1. |
It's your call. It's just that I wouldn't bend over backwards to accommodate a pathological edge case. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This restriction was due to an implementation detail in CSPRNG(). Now that CSPRNG() properly handles lengths exceeding INT_MAX, remove this artificial restriction. Refs: nodejs#47515
Landed in 8833099 |
CSPRNG implicitly casts the size_t length argument to a signed int when calling RAND_bytes(), which leaves it up to the caller to ensure that the length argument actually fits into such a signed int. However, not all call sites explicitly ensure that, which could lead to subtle bugs. In OpenSSL 3, use RAND_bytes_ex() instead, which does not require casting the length to a signed int. In OpenSSL 1.1.1, RAND_bytes_ex() is not supported, thus we have to process blocks of size INT_MAX one by one. PR-URL: #47515 Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Now that CSPRNG() does not silently fail when the length exceeds INT_MAX anymore, there is no need for the two relevant assertions in SecretKeyGenTraits anymore. Refs: nodejs#47515
CSPRNG implicitly casts the size_t length argument to a signed int when calling RAND_bytes(), which leaves it up to the caller to ensure that the length argument actually fits into such a signed int. However, not all call sites explicitly ensure that, which could lead to subtle bugs. In OpenSSL 3, use RAND_bytes_ex() instead, which does not require casting the length to a signed int. In OpenSSL 1.1.1, RAND_bytes_ex() is not supported, thus we have to process blocks of size INT_MAX one by one. PR-URL: #47515 Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: James M Snell <jasnell@gmail.com>
CSPRNG implicitly casts the size_t length argument to a signed int when calling RAND_bytes(), which leaves it up to the caller to ensure that the length argument actually fits into such a signed int. However, not all call sites explicitly ensure that, which could lead to subtle bugs. In OpenSSL 3, use RAND_bytes_ex() instead, which does not require casting the length to a signed int. In OpenSSL 1.1.1, RAND_bytes_ex() is not supported, thus we have to process blocks of size INT_MAX one by one. PR-URL: nodejs#47515 Reviewed-By: Richard Lau <rlau@redhat.com> Reviewed-By: James M Snell <jasnell@gmail.com>
This restriction was due to an implementation detail in CSPRNG(). Now that CSPRNG() properly handles lengths exceeding INT_MAX, remove this artificial restriction. Refs: nodejs#47515 PR-URL: nodejs#47559 Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com> Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Now that CSPRNG() does not silently fail when the length exceeds INT_MAX anymore, there is no need for the two relevant assertions in SecretKeyGenTraits anymore. Refs: nodejs#47515 PR-URL: nodejs#48053 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Now that CSPRNG() does not silently fail when the length exceeds INT_MAX anymore, there is no need for the two relevant assertions in SecretKeyGenTraits anymore. Refs: nodejs#47515 PR-URL: nodejs#48053 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Filip Skokan <panva.ip@gmail.com>
CSPRNG
implicitly casts thesize_t length
argument to a signedint
when callingRAND_bytes()
, which leaves it up to the caller to ensure that thelength
argument actually fits into such a signedint
. However, not all call sites explicitly ensure that, which could lead to subtle bugs.In OpenSSL 3, use
RAND_bytes_ex()
instead, which does not require casting thelength
to a signedint
.In OpenSSL 1.1.1,
RAND_bytes_ex()
is not supported, thus we have to process blocks of sizeINT_MAX
one by one.