[PATCH v5 0/1] MR10174: bcryptprimitives: Abort if ProcessPrng fails
[`ProcessPrng`] is documented as always returning TRUE. So I've modified `ProcessPrng` to abort on errors. This is I believe an import aspect of the function. See Microsoft's [The Windows 10 random number generation infrastructure] whitepaper.
We also have the property that a request for random bytes never fails. In the past our RNG functions could return an error code. We have observed that there are many callers that never check for the error code, even if they are generating cryptographic key material. This can lead to serious security vulnerabilities if an attacker manages to create a situation in which the RNG infrastructure returns an error. For that reason, the Win10 RNG infrastructure will never return an error code and always produce high-quality random bytes for every request.
[`ProcessPrng`]: https://learn.microsoft.com/en-us/windows/win32/seccng/processprng [The Windows 10 random number generation infrastructure]: https://www.microsoft.com/en-us/security/blog/2019/11/25/going-in-depth-on-t... -- v5: bcryptprimitives: Abort if ProcessPrng fails https://gitlab.winehq.org/wine/wine/-/merge_requests/10174
From: Chris Denton <chris@chrisdenton.dev> `ProcessPrng` is documented as always returning TRUE[1]. So I've modified `ProcessPrng` to do so. This is I believe an import aspect of the function. See Microsoft's "The Windows 10 random number generation infrastructure" whitepaper[2].
We also have the property that a request for random bytes never fails. In the past our RNG functions could return an error code. We have observed that there are many callers that never check for the error code, even if they are generating cryptographic key material. This can lead to serious security vulnerabilities if an attacker manages to create a situation in which the RNG infrastructure returns an error. For that reason, the Win10 RNG infrastructure will never return an error code and always produce high-quality random bytes for every request.
[1]: https://learn.microsoft.com/en-us/windows/win32/seccng/processprng [2]: https://www.microsoft.com/en-us/security/blog/2019/11/25/going-in-depth-on-t... --- dlls/bcryptprimitives/main.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/dlls/bcryptprimitives/main.c b/dlls/bcryptprimitives/main.c index 6562d672389..4e74ee5b679 100644 --- a/dlls/bcryptprimitives/main.c +++ b/dlls/bcryptprimitives/main.c @@ -23,5 +23,7 @@ BOOL WINAPI ProcessPrng(BYTE *data, SIZE_T size) { - return RtlGenRandom(data, size); + RtlGenRandom(data, size); + /* ProcessPrng is documented as always returning TRUE */ + return TRUE; } -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/10174
On Tue Feb 24 14:54:48 2026 +0000, Alfred Agrell wrote:
The commit message isn't accurate anymore, is it? Thanks, updated.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130369
On Tue Feb 24 14:54:48 2026 +0000, Christopher Denton wrote:
Thanks, updated. I mean the first line, the one saying abort.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130370
But in this form the original purpose is defeated, it in fact makes things worse in the sense of described motivation as now it won't return a theoretical error to the well behaving apps which would check it. But I personally doubt that such a change is useful (with abort or not). This is a random pick from Windows security mechanics which doesn't improve things in isolation. If we wanted to do what Windows does here for some reason maybe it would be more interesting in theory to make sure that we are not failing on underlying get random path. Aborting on PE side in a way Windows will never abort looks wrong. And as soon as it is not going to abort it is unneeded code. It is best to avoid unneeded PE side Wine specific things which diverge from Windows behaviour. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10174#note_130371
participants (4)
-
Alfred Agrell (＠Alcaro) -
Chris Denton
-
Christopher Denton (＠cdenton)
-
Paul Gofman (＠gofman)