Project: openssl (openssl/openssl), language: c++
Vulnerability instance: openssl.cve-2022-2274
Sanitizer: address

================= Bug Report (1/1) ==================
## Source: GitHub Issue
## URL: https://github.com/openssl/openssl/issues/18625
## Description:
Issue: openssl/openssl#18625
Title: AVX512-specific heap buffer overflow with 3.0.4 release
State: closed
Created by: xry111
Created at: 2022-06-22 08:51:51+00:00
Labels: branch: master, triaged: bug, branch: 3.0, severity: regression

Issue Body:
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
```


Comments:
Comment by xry111 on 2022-06-22 08:53:28+00:00:
Bisect shows 10d8a109be0fe50315e4eeb0676f6571914cd47a may be the culprit.

---

Comment by xry111 on 2022-06-22 08:58:53+00:00:
Also reproduciable with master branch.  Reverting 6d702cebfce3ffd9d8c0cb2af80a987d3288e7a3 can "fix" the issue.

---

Comment by xry111 on 2022-06-22 09:54:45+00:00:
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.

---

Comment by alex on 2022-06-22 12:03:05+00:00:
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.

---

Comment by alex on 2022-06-23 02:56:55+00:00:
Will a 3.0.5 release be done for this?

---

Comment by paulidale on 2022-06-23 03:09:10+00:00:
This will be definitely included in 3.0.5.  No decision has yet been made as to when that will occur.

---

Comment by alex on 2022-06-23 03:12:17+00:00:
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.

---

Comment by thesamesam on 2022-06-23 03:15:58+00:00:
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.

---

Comment by xry111 on 2022-06-23 04:05:31+00:00:
> 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.

---

Comment by t8m on 2022-06-23 05:50:15+00:00:
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.

---

Comment by alex on 2022-06-23 23:35:41+00:00:
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).

---

Comment by xry111 on 2022-06-24 04:25:38+00:00:
> 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.

---

Comment by reaperhulk on 2022-06-24 07:49:58+00:00:
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.

---

Comment by thesamesam on 2022-06-27 07:38:07+00:00:
FWIW, the post https://guidovranken.com/2022/06/27/notes-on-openssl-remote-memory-corruption/ seems to be doing the rounds.

---

Comment by kurtseifried on 2022-06-28 02:22:14+00:00:
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.

---

Comment by guidovranken on 2022-06-28 18:26:01+00:00:
> 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).

---

Comment by kurtseifried on 2022-06-29 02:33:49+00:00:
Thanks, done https://github.com/cloudsecurityalliance/gsd-database/pull/2357

---

Comment by paulidale on 2022-07-01 00:22:19+00:00:
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:
```sh
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.

---

Comment by davidben on 2022-07-01 04:56:04+00:00:
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](https://www.openssl.org/docs/manmaster/man3/OPENSSL_ia32cap.html), 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.

---

Comment by paulidale on 2022-07-01 06:39:37+00:00:
It has been tested.  It almost certainly disables extra stuff....  Hmmmm.....

---

Comment by paulidale on 2022-07-01 06:56:24+00:00:
Using `OPENSSL_ia32cap=:~0x200000` (disabling just AVX512IFMA) seems to fix the problem when I test it.

I've fixed the text above.

---

Comment by iamamoose on 2022-07-01 07:31:55+00:00:
https://www.cve.org/CVERecord?id=CVE-2022-2274

---

Comment by nektro on 2022-07-06 00:13:56+00:00:
https://www.openssl.org/news/secadv/20220705.txt new version with fix was tagged

---

Comment by khantext on 2022-07-06 14:17:38+00:00:
> 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?

---

Comment by guidovranken on 2022-07-06 16:02:17+00:00:
@khantext 

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

Yes. [Here](https://gist.github.com/guidovranken/4b468777d9f108a26a5a45ce62b88b17) 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](https://github.com/openssl/openssl/blob/2837b19fcba4bf4ff2ecdc8435c650bf18c27552/include/internal/packet.h#L27)) 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.

---

Comment by AKrasheninnikov on 2022-07-18 07:53:57+00:00:
Does it affect Microsoft's System.Security.Cryptography.OpenSsl libraries in any way?

---

Comment by xry111 on 2022-07-18 15:16:57+00:00:
> Does it affect Microsoft's System.Security.Cryptography.OpenSsl libraries in any way?

The [MS doc](https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.rsaopenssl?view=net-6.0) says:

> The [RSAOpenSsl](https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.rsaopenssl?view=net-6.0) 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](https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.rsa.create?view=net-6.0) 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.

Commit References:
2837b19fcba4bf4ff2ecdc8435c650bf18c27552
10d8a109be0fe50315e4eeb0676f6571914cd47a
6d702cebfce3ffd9d8c0cb2af80a987d3288e7a3

Build script:
#!/bin/bash -eu
# Minimized build script with only core build commands
set -eu
CONFIGURE_FLAGS=""
  CONFIGURE_FLAGS="no-asm"
make -j$(nproc) LDCMD="$CXX $CXXFLAGS"

Dockerfile:
FROM hwiwonlee/secb.base:latest
RUN apt-get update && apt-get install -y make
RUN git clone https://github.com/openssl/openssl openssl
RUN git -C openssl checkout 54f5fca0d0b15f912e7355a378976cbff12d58fc
WORKDIR $SRC/openssl
COPY build.sh $SRC/

Additional files:
filename: bignum.options
content: [libfuzzer]
max_len = 2048