Skip to content
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

AVX512-specific heap buffer overflow with 3.0.4 release #18625

Closed
xry111 opened this issue Jun 22, 2022 · 27 comments
Closed

AVX512-specific heap buffer overflow with 3.0.4 release #18625

xry111 opened this issue Jun 22, 2022 · 27 comments
Labels
branch: master Merge to master branch branch: 3.0 Merge to openssl-3.0 branch severity: regression The issue/pr is a regression from previous released version triaged: bug The issue/pr is/fixes a bug

Comments

@xry111
Copy link
Contributor

xry111 commented Jun 22, 2022

Build OpenSSL-3.0.4 on a CPU with AVX512 (my CPU is a Core i7-1065G7) with:

CFLAGS="-O3 -g -fsanitize=address" ./config
make

Run a test:

make V=1 TESTS=test_exp test

The sanitizer complains:

==481618==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60c000089400 at pc 0x7f01e32a9509 bp 0x7fff643ec100 sp 0x7fff643ec0f8
READ of size 8 at 0x60c000089400 thread T0
    #0 0x7f01e32a9508 in bn_select_words crypto/bn/rsaz_exp.h:64
    #1 0x7f01e32a9508 in bn_reduce_once_in_place crypto/bn/rsaz_exp.h:74
    #2 0x7f01e32a9508 in ossl_rsaz_mod_exp_avx512_x2 crypto/bn/rsaz_exp_x2.c:223
    #3 0x7f01e3287dc8 in BN_mod_exp_mont_consttime_x2 crypto/bn/bn_exp.c:1448
    #4 0x4042c3 in test_mod_exp_x2 test/exptest.c:260
    #5 0x40611a in run_tests test/testutil/driver.c:370
    #6 0x4039ba in main test/testutil/main.c:30
    #7 0x7f01e2c29319 in __libc_start_call_main (/usr/lib/libc.so.6+0x29319)
    #8 0x7f01e2c293e4 in __libc_start_main_impl (/usr/lib/libc.so.6+0x293e4)
    #9 0x403c40 in _start (/home/xry111/sources/lfs/openssl-3.0.4/test/exptest+0x403c40)

0x60c000089400 is located 0 bytes to the right of 128-byte region [0x60c000089380,0x60c000089400)
allocated by thread T0 here:
    #0 0x7f01e3ae5107 in __interceptor_malloc ../../../../libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x7f01e34aa7a8 in CRYPTO_zalloc crypto/mem.c:197

SUMMARY: AddressSanitizer: heap-buffer-overflow crypto/bn/rsaz_exp.h:64 in bn_select_words
Shadow bytes around the buggy address:
  0x0c1880009230: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
  0x0c1880009240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c1880009250: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c1880009260: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
  0x0c1880009270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c1880009280:[fa]fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c1880009290: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
  0x0c18800092a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c18800092b0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x0c18800092c0: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
  0x0c18800092d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==481618==ABORTING
@xry111 xry111 added the issue: bug report The issue was opened to report a bug label Jun 22, 2022
@xry111
Copy link
Contributor Author

xry111 commented Jun 22, 2022

Bisect shows 10d8a10 may be the culprit.

@xry111
Copy link
Contributor Author

xry111 commented Jun 22, 2022

Also reproduciable with master branch. Reverting 6d702ce can "fix" the issue.

@xry111
Copy link
Contributor Author

xry111 commented Jun 22, 2022

Note that this is not just a sanitizer-related issue: I'm pretty sure it will blow up on any CPU with AVX-512, with or without sanitizer. But w/o sanitizer the error message is just an unhelpful invalid free (caused by heap corruption) so I used sanitizer in the report.

xry111 added a commit to xry111/openssl that referenced this issue Jun 22, 2022
bn_reduce_once_in_place expects the number of BN_ULONG, but factor_size
is moduli bit size.

Fixes openssl#18625.

Signed-off-by: Xi Ruoyao <xry111@xry111.site>
@t8m t8m added branch: master Merge to master branch triaged: bug The issue/pr is/fixes a bug branch: 3.0 Merge to openssl-3.0 branch severity: regression The issue/pr is a regression from previous released version and removed issue: bug report The issue was opened to report a bug labels Jun 22, 2022
@alex
Copy link
Contributor

alex commented Jun 22, 2022

We (pyca/cryptography) have started receiving bug reports of heap-corruption with our latest release (which includes 3.0.4) that I assume have this as a root cause.

openssl-machine pushed a commit that referenced this issue Jun 23, 2022
bn_reduce_once_in_place expects the number of BN_ULONG, but factor_size
is moduli bit size.

Fixes #18625.

Signed-off-by: Xi Ruoyao <xry111@xry111.site>

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from #18626)

(cherry picked from commit 4d8a88c)
@alex
Copy link
Contributor

alex commented Jun 23, 2022

Will a 3.0.5 release be done for this?

@paulidale
Copy link
Contributor

This will be definitely included in 3.0.5. No decision has yet been made as to when that will occur.

@alex
Copy link
Contributor

alex commented Jun 23, 2022

I would strongly advocate for it to occur quickly. I think this issue qualifies as a CRITICAL within OpenSSL's vulnerability severity policy, and it makes it effectively impossible for users to upgrade to 3.0.4 to obtain its security fixes.

@thesamesam
Copy link
Contributor

thesamesam commented Jun 23, 2022

Yes, we're not rolling out 3.0.4 to users because of this bug (and the test build failure bug). I'm sure other distributions will be in a similar position, or will be once their users end up hitting this bug.

The alternative is a bunch of distributions end up cherry-picking patches from branches which helps nobody and isn't as safe as a release. Folks shipping e.g. Python wheels, as Alex does, don't have the luxury of doing that as easily, either.

@xry111
Copy link
Contributor Author

xry111 commented Jun 23, 2022

I would strongly advocate for it to occur quickly. I think this issue qualifies as a CRITICAL within OpenSSL's vulnerability severity policy, and it makes it effectively impossible for users to upgrade to 3.0.4 to obtain its security fixes.

Speaking as a @lfs-book editor: we are not fans of "marking every crash as a security vulnerability". But, we'd strongly prefer to receive a 3.0.5 release ASAP, instead of injecting the fix into the book.

@t8m
Copy link
Member

t8m commented Jun 23, 2022

I do not think this is a security vulnerability. It is just a serious bug making 3.0.4 release unusable on AVX512 capable machines.

Gusse500 added a commit to Gusse500/LFS-Norsk that referenced this issue Jun 23, 2022
c_rehash-skriptet, sendt av OpenSSL-versjoner i gjeldende LFS-trunk
og alle tidligere LFS-utgivelser, er sårbare for CVE-2022-2068. Det er
fikset i 3.0.4, men OpenSSL 3.0.4 er fullstendig ødelagt på CPU-modeller med
AVX-512 utvidelse [1]. Så vi vil gjerne utsette OpenSSL-oppdateringen og vente på
oppstrøms konsensus om "ville 3.0.5 bli utgitt i haster".

Men oppstrøms har kunngjort at bruk av c_rehash er foreldet nå [2].
Så vi kan fortelle folk at de ikke skal bruke den.

[1]: openssl/openssl#18625
[2]: https://www.openssl.org/news/secadv/20220621.txt
@alex
Copy link
Contributor

alex commented Jun 23, 2022

I'm not sure I understand how it's not a security vulnerability. It's a heap buffer overflow that's triggerable by things like RSA signatures, which can easily happen in remote contexts (e.g. a TLS handshake).

@xry111
Copy link
Contributor Author

xry111 commented Jun 24, 2022

I'm not sure I understand how it's not a security vulnerability. It's a heap buffer overflow that's triggerable by things like RSA signatures, which can easily happen in remote contexts (e.g. a TLS handshake).

Actually I don't like the idea of "marking every heap buffer overflow as a security vulnerability". Vim has started to do such thing in this year. Now we are being noised by about ten "high severity" vim CVEs per month, w/o any exploit in practice. I think we shouldn't mark a bug as "security vulnerability" unless we have some evidence showing it can (or at least, may) be expolited.

That being said, to me 3.0.5 should be released ASAP because this issue is very severe, regardless of it's a vulnerability or not.

@reaperhulk
Copy link
Contributor

I’ll also add my voice to those urging a quick 3.0.5 release as well. If that is not feasible then the openssl project should consider sending an email to the announcement/release list about this issue. Many people don’t follow the project closely enough to be aware that there is a known severe bug in the latest release.

@thesamesam
Copy link
Contributor

FWIW, the post https://guidovranken.com/2022/06/27/notes-on-openssl-remote-memory-corruption/ seems to be doing the rounds.

@kurtseifried
Copy link

The Global Security Database (https://globalsecuritydatabase.org/) has assigned this GSD-2022-1002526 (https://edit.globalsecuritydatabase.org/identifier/GSD-2022-1002526) for tracking purposes. Please feel free to update it if you see anything incorrect or missing. Thanks.

@guidovranken
Copy link
Contributor

The Global Security Database (https://globalsecuritydatabase.org/) has assigned this GSD-2022-1002526 (https://edit.globalsecuritydatabase.org/identifier/GSD-2022-1002526) for tracking purposes. Please feel free to update it if you see anything incorrect or missing. Thanks.

Correction to:

In OpenSSL version 3.0.4 a heap buffer overflow exists in the AVX512 support that can be attacked via network resulting in code execution. This is reachable via four code paths: RSAZ 1024, RSAZ 512, Dual 1024 RSAZ, and Default constant-time Montgomery modular exponentiation.

It is only reachable via Dual 1024 RSAZ, which in turn is only reachable via RSA operations. Someone correct me if I'm wrong.

The four code paths mentioned to in the blog post referred to a different issue (without security impact). The fix for that issue created the buffer overflow in dual 1024 RSAZ (but not in the other code paths).

@kurtseifried
Copy link

Thanks, done cloudsecurityalliance/gsd-database#2357

gentoo-bot pushed a commit to gentoo/gentoo that referenced this issue Jun 30, 2022
Bug: openssl/openssl#18625
Signed-off-by: Sam James <sam@gentoo.org>
@paulidale
Copy link
Contributor

paulidale commented Jul 1, 2022

This vulnerability have been allocated the CVE-2022-2274 name.
It has been classified by the project as HIGH severity.

There is a workaround that can be used until the 3.0.5 release is done:

export OPENSSL_ia32cap=:~0x200000

We anticipate that the 3.0.5 release will be done on Tuesday the 5th of July.

Edit: corrected the value in the workaround.

@davidben
Copy link
Contributor

davidben commented Jul 1, 2022

Is that the right workaround? Have you all tested it? Are you sure it'll work correctly on all CPUs? Are you sure it does not disable additional features?

Based on the documentation, using a bare value (as opposed to ~) overwrites the entire word. That means you'll disable every feature not included in 0x15, and assume the presence of every feature included in 0x15. The masking version seems more appropriate.

@paulidale
Copy link
Contributor

paulidale commented Jul 1, 2022

It has been tested. It almost certainly disables extra stuff.... Hmmmm.....

@paulidale
Copy link
Contributor

Using OPENSSL_ia32cap=:~0x200000 (disabling just AVX512IFMA) seems to fix the problem when I test it.

I've fixed the text above.

@iamamoose
Copy link
Member

@nektro
Copy link

nektro commented Jul 6, 2022

https://www.openssl.org/news/secadv/20220705.txt new version with fix was tagged

@khantext
Copy link

khantext commented Jul 6, 2022

It is only reachable via Dual 1024 RSAZ, which in turn is only reachable via RSA operations.

@guidovranken et al.:
From a security practitioner's perspective, I am struggling to understand the specifics and practical implications of this bug based upon my readings across the interwebs. It appears that NIST (NVD) may not yet understand either, given that they have not published any CVSS scoring. Any assistance in answering the following would be greatly appreciated.

For each, is it true, false, or indeterminate?

  • An attacker could theoretically exploit this vulnerability by sending a transmission across a network (e.g., a TCP/IP network)?
  • A successful exploit could theoretically...
    • disrupt services (i.e., DoS);
    • steal information in memory (i.e., confidentiality breach);
    • alter information in memory (i.e., integrity breach);
    • invoke/execute a definable list of specific actions on the target application/host;
    • invoke/execute arbitrary commands/code on the target application/host.

If network-based attacks are possible, I'd also be interested in your informed takes on the difficulty and, thus, the likelihood of each type of attack occurring.

It is understood that software component enumeration (looking for OpenSSL 3.0.4) and hardware enumeration (looking for chips implementing AVX-512) can tell us where we are definitely vulnerable.

Are there "black box" indicators that would be informative, even if not definitive? For example, I believe I can check the public keys on my web servers to determine if they are using RSA 2048bit. Are there other positive or negative indicators (not necessarily proofs) one could potentially see from the outside?

@guidovranken
Copy link
Contributor

@khantext

An attacker could theoretically exploit this vulnerability by sending a transmission across a network

Yes. Here is a program (derived from the OpenSSL server fuzzer code) which sets up an SSL server and sends an offending payload. It uses memory buffers rather than TCP/IP but they are functionally analogous.

With AddressSanitizer enabled, this crashes as follows:

=================================================================
==671281==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61200000225f at pc 0x0000009800c2 bp 0x7ffcf8dd0b30 sp 0x7ffcf8dd0b28
READ of size 32 at 0x61200000225f thread T0
    #0 0x9800c1 in bn_select_words /home/ubuntu/gh-issue/openssl-3.0.4/crypto/bn/rsaz_exp.h:64:46
    #1 0x9800c1 in bn_reduce_once_in_place /home/ubuntu/gh-issue/openssl-3.0.4/crypto/bn/rsaz_exp.h:74:5
    #2 0x9800c1 in ossl_rsaz_mod_exp_avx512_x2 /home/ubuntu/gh-issue/openssl-3.0.4/crypto/bn/rsaz_exp_x2.c:223:5
    #3 0x96ae63 in BN_mod_exp_mont_consttime_x2 /home/ubuntu/gh-issue/openssl-3.0.4/crypto/bn/bn_exp.c:1448:15
    #4 0x771f8f in rsa_ossl_mod_exp /home/ubuntu/gh-issue/openssl-3.0.4/crypto/rsa/rsa_ossl.c:702:17
    #5 0x7711d3 in rsa_ossl_private_decrypt /home/ubuntu/gh-issue/openssl-3.0.4/crypto/rsa/rsa_ossl.c:442:14
    #6 0x818db6 in rsa_decrypt /home/ubuntu/gh-issue/openssl-3.0.4/providers/implementations/asymciphers/rsa_enc.c:238:15
    #7 0x5bef21 in tls_process_cke_rsa /home/ubuntu/gh-issue/openssl-3.0.4/ssl/statem/statem_srvr.c:2924:16
    #8 0x5bef21 in tls_process_client_key_exchange /home/ubuntu/gh-issue/openssl-3.0.4/ssl/statem/statem_srvr.c:3306:14
    #9 0x57f159 in read_state_machine /home/ubuntu/gh-issue/openssl-3.0.4/ssl/statem/statem.c:647:19
    #10 0x57f159 in state_machine /home/ubuntu/gh-issue/openssl-3.0.4/ssl/statem/statem.c:442:21
    #11 0x4f56b1 in SSL_do_handshake /home/ubuntu/gh-issue/openssl-3.0.4/ssl/ssl_lib.c:3923:19
    #12 0x4f6b8b in SSL_accept /home/ubuntu/gh-issue/openssl-3.0.4/ssl/ssl_lib.c:1735:12
    #13 0x4f6b8b in SSL_read_early_data /home/ubuntu/gh-issue/openssl-3.0.4/ssl/ssl_lib.c:1911:15
    #14 0x4c9a29 in main /home/ubuntu/gh-issue/openssl-3.0.4/server.c:637:19
    #15 0x7fb8d6116082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
    #16 0x41d06d in _start (/home/ubuntu/gh-issue/openssl-3.0.4/a.out+0x41d06d)

0x61200000225f is located 15 bytes to the right of 272-byte region [0x612000002140,0x612000002250)
allocated by thread T0 here:
    #0 0x4982cd in malloc (/home/ubuntu/gh-issue/openssl-3.0.4/a.out+0x4982cd)
    #1 0x70bdcd in CRYPTO_malloc /home/ubuntu/gh-issue/openssl-3.0.4/crypto/mem.c:190:12
    #2 0x70bdcd in CRYPTO_zalloc /home/ubuntu/gh-issue/openssl-3.0.4/crypto/mem.c:197:11
    #3 0x61327d in bn_expand_internal /home/ubuntu/gh-issue/openssl-3.0.4/crypto/bn/bn_lib.c:281:13
    #4 0x61327d in bn_expand2 /home/ubuntu/gh-issue/openssl-3.0.4/crypto/bn/bn_lib.c:305:23
    #5 0x95c46e in bn_div_fixed_top /home/ubuntu/gh-issue/openssl-3.0.4/crypto/bn/bn_div.c:327:10
    #6 0x95bd99 in BN_div /home/ubuntu/gh-issue/openssl-3.0.4/crypto/bn/bn_div.c:229:11
    #7 0x61caa6 in BN_MONT_CTX_set /home/ubuntu/gh-issue/openssl-3.0.4/crypto/bn/bn_mont.c:397:10
    #8 0x961d72 in BN_mod_exp_mont_consttime /home/ubuntu/gh-issue/openssl-3.0.4/crypto/bn/bn_exp.c:645:14
    #9 0x95f15c in BN_mod_exp_mont /home/ubuntu/gh-issue/openssl-3.0.4/crypto/bn/bn_exp.c:309:16
    #10 0x956f0e in BN_BLINDING_create_param /home/ubuntu/gh-issue/openssl-3.0.4/crypto/bn/bn_blind.c:294:14
    #11 0x768b34 in RSA_setup_blinding /home/ubuntu/gh-issue/openssl-3.0.4/crypto/rsa/rsa_crpt.c:155:15
    #12 0x771081 in rsa_get_blinding /home/ubuntu/gh-issue/openssl-3.0.4/crypto/rsa/rsa_ossl.c:170:25
    #13 0x771081 in rsa_ossl_private_decrypt /home/ubuntu/gh-issue/openssl-3.0.4/crypto/rsa/rsa_ossl.c:420:20
    #14 0x818db6 in rsa_decrypt /home/ubuntu/gh-issue/openssl-3.0.4/providers/implementations/asymciphers/rsa_enc.c:238:15
    #15 0x5bef21 in tls_process_cke_rsa /home/ubuntu/gh-issue/openssl-3.0.4/ssl/statem/statem_srvr.c:2924:16
    #16 0x5bef21 in tls_process_client_key_exchange /home/ubuntu/gh-issue/openssl-3.0.4/ssl/statem/statem_srvr.c:3306:14
    #17 0x57f159 in read_state_machine /home/ubuntu/gh-issue/openssl-3.0.4/ssl/statem/statem.c:647:19
    #18 0x57f159 in state_machine /home/ubuntu/gh-issue/openssl-3.0.4/ssl/statem/statem.c:442:21
    #19 0x4f56b1 in SSL_do_handshake /home/ubuntu/gh-issue/openssl-3.0.4/ssl/ssl_lib.c:3923:19
    #20 0x4f6b8b in SSL_accept /home/ubuntu/gh-issue/openssl-3.0.4/ssl/ssl_lib.c:1735:12
    #21 0x4f6b8b in SSL_read_early_data /home/ubuntu/gh-issue/openssl-3.0.4/ssl/ssl_lib.c:1911:15
    #22 0x4c9a29 in main /home/ubuntu/gh-issue/openssl-3.0.4/server.c:637:19
    #23 0x7fb8d6116082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16

disrupt services (i.e., DoS)

Yes.

If the application halts upon crashing, a single payload transmission constitutes a succesful DoS attack.

If the embedding application (e.g. Apache web server) automatically respawns after crashing, then repeated transmissions will render the server mostly unusable.

The ratio between the cost of launching the attack (sending only 2 dozen bytes of payload) vs. the cost of bearing the attack (crashing and respawning) is high, so it's trivial to do this from basic hardware and network connection.

steal information in memory (i.e., confidentiality breach)

Three buffer are overwritten: res1, res2 and storage. There are 2 arrays which are read, but not written to: m1 and m2. After the buffer overflow:

  • The values of m1 can be inferred from res1.
  • The values of m2 can be inferred from res2.
  • If res2 is known, the values of m2 can be inferred from storage.
  • If m2 is known, the values of res2 can be inferred from storage.

From this it follows that if the attacker controls a certain region (e.g. the values pre-overwrite can be known or defined, and the values post-overwrite can be read), then the values of an unrelated memory region (which may (but not necessarily does) contain sensitive information), can be known.

A region can be controlled by the attacker if it is allocated by either:

  • the OpenSSL TLS state machine, and its contents is sent back at a later step in the protocol flow
  • an equivalent procedure performed the embedding application (e.g. web server)

For this to work it is imperative that a crash due to corrupted malloc chunks does not occur, either by chance or by manipulation by the attacker.

alter information in memory (i.e., integrity breach)

If the attacker controls the contents of a region (e.g. m1), and res1 is known to constitute some internal data structure, and the pre-overwrite contents of res1 is known, then the data structure contents can be filled in with bytes of the attacker's choosing.

Apart from this it is also necessary to avert a crash for the data structure rewrite to be meaningful.

Impacting the integrity of certain data structures (e.g. increasing the remaining field of a PACKET) may lead to additional escalation.

invoke/execute a definable list of specific actions on the target application/host
invoke/execute arbitrary commands/code on the target application/host

I don't see any reason to rule out a full compromise. Despite the fact that all inputs to the modexp function are unknown to the attacker (private key components, blinding factor), these inputs bear little relation to the post-overwrite state of the out-of-bounds memory. Given that OpenSSL makes heavy use of function pointers, overwriting a pointer to refer to execve or similar may be fruitful. Furthermore, the subtraction logic performed by bn_reduce_once_in_place lends itself to circumventing ASLR without prior knowledge of the (randomized) memory layout, as shown in the blog post.

I want to note that each of these except DoS are speculative and not trivial to perform, and are predicated upon meticulously controlling the regions that are overread and overwritten by way of influencing the state machine flow, though automatic exploit generators based on symbolic execution reportedly do exist.

For applications that immediately respawn the exploit does not have to be very reliable. If it works as intended 1/10000th of the time that's good enough to eventually achieve the goal.

@AKrasheninnikov
Copy link

Does it affect Microsoft's System.Security.Cryptography.OpenSsl libraries in any way?

@xry111
Copy link
Contributor Author

xry111 commented Jul 18, 2022

Does it affect Microsoft's System.Security.Cryptography.OpenSsl libraries in any way?

The MS doc says:

The RSAOpenSsl class is an implementation of the RSA algorithm using OpenSSL. It isn't available on Windows and is only available on other operating systems when OpenSSL is installed. For applications which aren't doing OpenSSL-specific interop, you're encouraged to use RSA.Create instead of referencing this type directly.

It seems suggesting that RSAOpenSsl is a language binding for system OpenSSL. So if the version of OpenSSL installed on the system is affected, RSAOpenSsl is affected.

sftcd pushed a commit to sftcd/openssl that referenced this issue Sep 24, 2022
bn_reduce_once_in_place expects the number of BN_ULONG, but factor_size
is moduli bit size.

Fixes openssl#18625.

Signed-off-by: Xi Ruoyao <xry111@xry111.site>

Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from openssl#18626)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
branch: master Merge to master branch branch: 3.0 Merge to openssl-3.0 branch severity: regression The issue/pr is a regression from previous released version triaged: bug The issue/pr is/fixes a bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.