[OpenSSL compatibility]: 5.6.6 and/or v5.6.6-stable-564-g3129e29a1 do not fill int pointed to by 2nd argument to SSL_CIPHER_get_bits(sc, &bitsalg);

[mandree]

Contact Details

(use Gitlab)

Version

v5.6.6-stable-564-g3129e29a1

Description

Apparently OpenSSL fills in the bits into the int pointed to by the 2nd argument of SSL_CIPHER_get_bits(sc, &i); in addition to returning them. I haven't found this documented for OpenSSL, but it's in use in the wild and appears to, once upon a time, have been a means to reveal weakened algorithms that only used, say 40 out of 128 bits.

Reproduction steps

Use WolfSSL's OpenSSL compatibility layer,
establish a TLS client connection,
have it connect and negotiate a cipher (assuming SSL_CIPHER *sc is extant and initialized properly), then call:

int bits1;
int bits2 = -23;
bits1 = SSL_CIPHER_get_bits(sc, &bits2);

and see bits2 unchanged, whereas OpenSSL 1.1.1, 3.0 or 3.1 would fill in 128 or 256 on my typical AES-encrypting ciphers.

Relevant log output

No response

[anhu]

Hi @mandree,

My name is Anthony and I am a member of the wolfSSL team. Can you please let me know what configuration flags you are using?

*alg_bits is set if you have OPENSSL_ALL defined. If you use configure , add --enable-opensslall .

Can you also please let us know a bit about yourself and your project? For example, Where are you located? Are you using wolfSSL in a personal, academic or professional project? Are there any institutions associated with this project? What are you trying to achieve? We love knowing about how people are using our code. Please feel free to share whatever you comfortable with.

Warm regards, Anthony

[mandree]

Hi Anthony, this is a finding I've had with the open-source fetchmail project (https://www.fetchmail.info/ or https://gitlab.com/fetchmail/fetchmail on the legacy_6x branch) that I maintain and where wolfSSL might be easier to link to license-wise whilst still supporting TLS v1.3.

The most recent I'd tested is wolfSSL from said git commit (see initial report, above) with
a sub-directory to build and then:

CONFIG_SHELL=/bin/sh /bin/sh ../configure -C --enable-context-extra-user-data --enable-debug --enable-opensslall --enable-harden --prefix=/opt/wolfssl CFLAGS='-O2 -DOPENSSL_COMPATIBLE_DEFAULTS -g'

I am running this with wolfSSL 5 against two sites, once forcing TLSv1.2, once forcing TLSv1.3, and get:

Mar 30 15:50:46 fetchmail: SSL/TLS: using protocol TLSv1.2, cipher TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, 256/-9999 secret/processed bits
Mar 30 15:50:46 fetchmail: SSL/TLS: using protocol TLSv1.2, cipher TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 128/-9999 secret/processed bits
Mar 30 15:50:47 fetchmail: SSL/TLS: using protocol TLSv1.3, cipher TLS_AES_256_GCM_SHA384, 256/-9999 secret/processed bits
Mar 30 15:50:47 fetchmail: SSL/TLS: using protocol TLSv1.3, cipher TLS_AES_128_GCM_SHA256, 128/-9999 secret/processed bits

Compare this with an OpenSSL 3.1.1 (probably with some patches) provided for Fedora Linux:

fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384, 256/256 secret/processed bits
fetchmail: SSL/TLS: using protocol TLSv1.2, cipher ECDHE-ECDSA-CHACHA20-POLY1305, 256/256 secret/processed bits
fetchmail: SSL/TLS: using protocol TLSv1.3, cipher TLS_AES_256_GCM_SHA384, 256/256 secret/processed bits
fetchmail: SSL/TLS: using protocol TLSv1.3, cipher TLS_AES_256_GCM_SHA384, 256/256 secret/processed bits

Example code - I already initialize the output field to -9999 here to mark it's not being dealt with - and "garbage" might be whatever we find on the stack, and I previously saw that and worked around it in fetchmail.

        if (outlevel >= O_VERBOSE) {
            SSL_CIPHER const *sc;
            int bitsalg = -9999, bitsused; /* initialize bitsalg to avoid picking up random garbage with WolfSSL, which does not fill this, as of 5.6.6 */

            const char *vers;

            vers = SSL_get_version(_ssl_context[sock]);

            sc = SSL_get_current_cipher(_ssl_context[sock]);
            if (!sc) {
                report (stderr, GT_("Cannot obtain current SSL/TLS cipher - no session established?\n"));
            } else {
                bitsused = SSL_CIPHER_get_bits(sc, &bitsalg);
                report(stdout, ("SSL/TLS: using protocol %s, cipher %s, %d/%d secret/processed bits\n"),
                        vers, SSL_CIPHER_get_name(sc), bitsused, bitsalg);
            }
        }

[anhu]

Hi @mandree ,

I'm so sorry that I have let this issue go stale. Please accept my apologies. May I ask, are you still seeing this issue?

Warm regards, Anthony

[mandree]

Can't say, it won't build nor install. Fedora 42 Linux on x86_64,

wolfSSL Git version 4c273a6,

./configure --enable-opensslall --enable-harden --enable-context-extra-user-data --prefix=/opt/wolfssl 'CFLAGS=-DOPENSSL_COMPATIBLE_DEFAULTS\ -DWOLFSSL_BLIND_PRIVATE_KEY\ -O3 -flto' --enable-debug

-> make or "sudo make install" end in error:

CCLD     tests/unit.test
/usr/sbin/ld: /tmp/ccx65CUr.ltrans0.ltrans.o:(.data+0x3ef0): undefined reference to `test_wolfSSL_sk_new_free_node'
/usr/sbin/ld: /tmp/ccx65CUr.ltrans0.ltrans.o:(.data+0x3f10): undefined reference to `test_wolfSSL_sk_push_get_node'
/usr/sbin/ld: /tmp/ccx65CUr.ltrans0.ltrans.o:(.data+0x3f30): undefined reference to `test_wolfSSL_sk_free'
/usr/sbin/ld: /tmp/ccx65CUr.ltrans0.ltrans.o:(.data+0x3f50): undefined reference to `test_wolfSSL_sk_push_pop'
/usr/sbin/ld: /tmp/ccx65CUr.ltrans0.ltrans.o:(.data+0x3f70): undefined reference to `test_wolfSSL_sk_insert'
/usr/sbin/ld: /tmp/ccx65CUr.ltrans0.ltrans.o:(.data+0x3f90): undefined reference to `test_wolfSSL_shallow_sk_dup'
/usr/sbin/ld: /tmp/ccx65CUr.ltrans0.ltrans.o:(.data+0x3fb0): undefined reference to `test_wolfSSL_sk_num'
/usr/sbin/ld: /tmp/ccx65CUr.ltrans0.ltrans.o:(.data+0x3fd0): undefined reference to `test_wolfSSL_sk_value'
/usr/sbin/ld: /tmp/ccx65CUr.ltrans0.ltrans.o:(.data+0x3ff0): undefined reference to `test_wolfssl_sk_GENERIC'
/usr/sbin/ld: /tmp/ccx65CUr.ltrans0.ltrans.o:(.data+0x4010): undefined reference to `test_wolfssl_sk_SSL_COMP'
/usr/sbin/ld: /tmp/ccx65CUr.ltrans0.ltrans.o:(.data+0x4030): undefined reference to `test_wolfSSL_sk_CIPHER'
/usr/sbin/ld: /tmp/ccx65CUr.ltrans0.ltrans.o:(.data+0x4050): undefined reference to `test_wolfssl_sk_WOLFSSL_STRING'
/usr/sbin/ld: /tmp/ccx65CUr.ltrans0.ltrans.o:(.data+0x4070): undefined reference to `test_wolfssl_lh_retrieve'
collect2: error: ld returned 1 exit status

[anhu]

Interesting. I'm seeing a segfault. Please stay tuned.

[anhu]

It appears the macro WOLFSSL_BLIND_PRIVATE_KEY is causing problems. I'll look into root cause/fixes.

[mandree]

Stripped down to ./configure --enable-opensslall --enable-harden --enable-context-extra-user-data --prefix=/opt/wolfssl 'CFLAGS=-DOPENSSL_COMPATIBLE_DEFAULTS -O2' --enable-debug, I can compile and I can state that the problem persists.

[anhu]

Odd, I'm not seeing this on my ubuntu machine. Could it be that you have an older version of wolfSSL installed in /usr/local or /opt/wolfssl` and the configuration there is interfering with your build?

[anhu]

These function are implemented in tests/api/test_ossl_sk.c . Could it be that your build scripts are out of date? Before running ./configure can you try running ./autogen.sh first?

[mandree]

I can test, I've moved to Git 92fffa1 and re-run autogen.sh.

./configure --enable-opensslall --enable-harden --enable-context-extra-user-data --prefix=/opt/wolfssl 'CFLAGS=-DOPENSSL_COMPATIBLE_DEFAULTS -DWOLFSSL_BLIND_PRIVATE_KEY -Og -g' --disable-debug

now fails to build like this (cc and gcc are both [g]cc (GCC) 15.2.1 20251022 (Red Hat 15.2.1-3) on Fedora Linux 42 x86_64):

make[2]: warning: -j17 forced in submake: resetting jobserver mode.
  CC       tests/unit_test-api.o
  CC       tests/api/unit_test-test_ossl_sk.o
In file included from tests/api/test_ossl_sk.c:22:
tests/api/test_ossl_sk.c: In function 'test_wolfSSL_sk_push_get_node':
./tests/unit.h:186:12: error: 'node' may be used uninitialized [-Werror=maybe-uninitialized]
  186 |         if (!(test))                                                         \
      |            ^
./tests/unit.h:251:9: note: in expansion of macro 'Expect'
  251 |         Expect(_x op _y, ("%s " #op " %s", #x, #y), ("%p " #er " %p", _x, _y));\
      |         ^~~~~~
./tests/unit.h:256:27: note: in expansion of macro 'ExpectPtr'
  256 | #define ExpectPtrEq(x, y) ExpectPtr(x, y, ==, !=)
      |                           ^~~~~~~~~
tests/api/test_ossl_sk.c:79:5: note: in expansion of macro 'ExpectPtrEq'
   79 |     ExpectPtrEq(node, node1);
      |     ^~~~~~~~~~~
tests/api/test_ossl_sk.c:58:20: note: 'node' was declared here
   58 |     WOLFSSL_STACK* node;
      |                    ^~~~
cc1: all warnings being treated as errors
make[2]: *** [Makefile:10525: tests/api/unit_test-test_ossl_sk.o] Error 1
make[2]: *** Waiting for unfinished jobs....
In file included from tests/api.c:32:
tests/api.c: In function 'SSL_read_test_client_thread':
./tests/unit.h:186:12: error: 'ret' may be used uninitialized [-Werror=maybe-uninitialized]
  186 |         if (!(test))                                                         \
      |            ^
./tests/unit.h:212:9: note: in expansion of macro 'Expect'
  212 |         Expect(_x op _y, ("%s " #op " %s", #x, #y), ("%d " #er " %d", _x, _y));\
      |         ^~~~~~
./tests/unit.h:216:27: note: in expansion of macro 'ExpectInt'
  216 | #define ExpectIntEQ(x, y) ExpectInt(x, y, ==, !=)
      |                           ^~~~~~~~~
tests/api.c:42606:5: note: in expansion of macro 'ExpectIntEQ'
42606 |     ExpectIntEQ(ret, WOLFSSL_SUCCESS);
      |     ^~~~~~~~~~~
tests/api.c:42554:10: note: 'ret' was declared here
42554 |     int  ret, err;
      |          ^~~
tests/api.c: In function 'test_wolfSSL_d2i_OCSP_CERTID':
./tests/unit.h:186:12: error: 'certIdGood' may be used uninitialized [-Werror=maybe-uninitialized]
  186 |         if (!(test))                                                         \
      |            ^
./tests/unit.h:251:9: note: in expansion of macro 'Expect'
  251 |         Expect(_x op _y, ("%s " #op " %s", #x, #y), ("%p " #er " %p", _x, _y));\
      |         ^~~~~~
./tests/unit.h:256:27: note: in expansion of macro 'ExpectPtr'
  256 | #define ExpectPtrEq(x, y) ExpectPtr(x, y, ==, !=)
      |                           ^~~~~~~~~
tests/api.c:34187:9: note: in expansion of macro 'ExpectPtrEq'
34187 |         ExpectPtrEq(certIdGood, certId);
      |         ^~~~~~~~~~~
tests/api.c:34146:26: note: 'certIdGood' was declared here
34146 |     WOLFSSL_OCSP_CERTID* certIdGood;
      |                          ^~~~~~~~~~
tests/api.c: In function 'test_wolfSSL_d2i_and_i2d_PublicKey':
./tests/unit.h:186:12: error: 'derLen' may be used uninitialized [-Werror=maybe-uninitialized]
  186 |         if (!(test))                                                         \
      |            ^
./tests/unit.h:212:9: note: in expansion of macro 'Expect'
  212 |         Expect(_x op _y, ("%s " #op " %s", #x, #y), ("%d " #er " %d", _x, _y));\
      |         ^~~~~~
./tests/unit.h:216:27: note: in expansion of macro 'ExpectInt'
  216 | #define ExpectIntEQ(x, y) ExpectInt(x, y, ==, !=)
      |                           ^~~~~~~~~
tests/api.c:33830:5: note: in expansion of macro 'ExpectIntEQ'
33830 |     ExpectIntEQ(derLen, sizeof_client_keypub_der_2048);
      |     ^~~~~~~~~~~
tests/api.c:33821:9: note: 'derLen' was declared here
33821 |     int derLen;
      |         ^~~~~~
tests/api.c: In function 'test_wolfSSL_d2i_and_i2d_PublicKey_ecc':
./tests/unit.h:186:12: error: 'derLen' may be used uninitialized [-Werror=maybe-uninitialized]
  186 |         if (!(test))                                                         \
      |            ^
./tests/unit.h:212:9: note: in expansion of macro 'Expect'
  212 |         Expect(_x op _y, ("%s " #op " %s", #x, #y), ("%d " #er " %d", _x, _y));\
      |         ^~~~~~
./tests/unit.h:216:27: note: in expansion of macro 'ExpectInt'
  216 | #define ExpectIntEQ(x, y) ExpectInt(x, y, ==, !=)
      |                           ^~~~~~~~~
tests/api.c:33898:5: note: in expansion of macro 'ExpectIntEQ'
33898 |     ExpectIntEQ(derLen, pub_spki_len);
      |     ^~~~~~~~~~~
tests/api.c:33856:9: note: 'derLen' was declared here
33856 |     int derLen;
      |         ^~~~~~
cc1: all warnings being treated as errors
make[2]: *** [Makefile:9573: tests/unit_test-api.o] Error 1
make[2]: Leaving directory '/home/mandree/VCS-other/wolfssl.git'
make[1]: *** [Makefile:10797: check-recursive] Error 1
make[1]: Leaving directory '/home/mandree/VCS-other/wolfssl.git'
make: *** [Makefile:11291: check] Error 2

If I change to enabling debug,
./configure --enable-opensslall --enable-harden --enable-context-extra-user-data --prefix=/opt/wolfssl 'CFLAGS=-DOPENSSL_COMPATIBLE_DEFAULTS -DWOLFSSL_BLIND_PRIVATE_KEY -Og -g' --enable-debug

I get a crash in "make check" instead from the unit tests
-> test-suite.log.gz

And this is the backtrace:

Thread 1 "unit.test" received signal SIGSEGV, Segmentation fault.
0x00007ffff7f1b490 in DoTls13ClientHello (ssl=0x9c1600, input=0x996eb0 "\001", inOutIdx=0x9c1894, helloSz=232) at src/tls13.c:6937
6937        ssl->session->sessionIDSz = sessIdSz;
(gdb) bt full
#0  0x00007ffff7f1b490 in DoTls13ClientHello (ssl=0x9c1600, input=0x996eb0 "\001", inOutIdx=0x9c1894, helloSz=232) at src/tls13.c:6937
        b = 0 '\000'
        sessIdSz = 0 '\000'
        wantDowngrade = 0
        totalExtSz = 0
        ret = 0
        args = {{pv = {major = 3 '\003', minor = 3 '\003'}, idx = 39, begin = 4, usingPSK = 0}}
#1  0x00007ffff7f20a4f in DoTls13HandShakeMsgType (ssl=0x9c1600, input=0x996eb0 "\001", inOutIdx=0x9c1894, type=1 '\001', size=232, totalSz=236) at src/tls13.c:12821
        ret = 0
        tmp = 0
        inIdx = 4
        alertType = 236
#2  0x00007ffff7f210ab in DoTls13HandShakeMsg (ssl=0x9c1600, input=0x996eb0 "\001", inOutIdx=0x9c1894, totalSz=236) at src/tls13.c:13166
        ret = 0
        inputLength = 236
        type = 1 '\001'
        size = 232
        __func__ = "DoTls13HandShakeMsg"
#3  0x00007ffff7e7e04f in DoProcessReplyEx (ssl=0x9c1600, allowSocketErr=0) at src/internal.c:22903
        ret = 0
        type = 80
        readSz = 5
        atomicUser = 0
        __func__ = "DoProcessReplyEx"
#4  0x00007ffff7e7e7f9 in ProcessReplyEx (ssl=0x9c1600, allowSocketErr=0) at src/internal.c:23276
        ret = 32767
#5  0x00007ffff7e7e7d7 in ProcessReply (ssl=0x9c1600) at src/internal.c:23269
No locals.
#6  0x00007ffff7ed7142 in wolfSSL_accept (ssl=0x9c1600) at src/ssl.c:10995
        havePSK = 0
        haveAnon = 0
        haveMcast = 0
        ret = 0
        __func__ = "wolfSSL_accept"
#7  0x00000000007211a6 in test_wolfSSL_BIO_accept () at tests/api/test_ossl_bio.c:855
        _x = 32767
        _y = -139159496
        _ret = 1
        _fail_codepoint_id = 0
        serverBindBio = 0x9a85a0
        serverAcceptBio = 0x9db910
        sslServer = 0x9c1600
        ctx = 0x9dac80
        args = {argc = 0, argv = 0x0, return_code = 0, signal = 0x0, callbacks = 0x0}
        thread = 140737315169984
        port = "11111\000\377\177\000"
#8  0x00000000005b6e7d in ApiTest () at tests/api.c:51983
        _ret = 3
        _fail_codepoint_id = 0
        lastGroup = 0x816f8e "ossl_bio_tls"
        i = 1095
        ret = 1
        res = 1
        timeDiff = 1762974165.530858
        passed = 674
        skipped = 420
        failed = 1
#9  0x0000000000407dfc in unit_test (argc=1, argv=0x7fffffffd1a8) at tests/unit.c:284
        ret = 0
#10 0x00000000004079ad in main (argc=1, argv=0x7fffffffd1a8) at tests/unit.c:46
No locals.

Either way, the originally reported issue persists:

...
Nov 12 20:05:26 fetchmail: SSL/TLS: using protocol TLSv1.3, cipher TLS_AES_256_GCM_SHA384, 256/-9999 secret/processed bits
...

(ditto when enforcing TLSv1.2) - the "processed bits" remain unwritten to by wolfSSL. Source code:

https://gitlab.com/fetchmail/fetchmail/-/blob/6.6.1/socket.c?ref_type=tags#L1567 where the offending code is on lines 1579 - 1581:

		bitsused = SSL_CIPHER_get_bits(sc, &bitsalg);
		report(stdout, ("SSL/TLS: using protocol %s, cipher %s, %d/%d secret/processed bits\n"),
			vers, SSL_CIPHER_get_name(sc), bitsused, bitsalg);

(The excess parens might have been remnants of a GT_ call that should localize the text.)

The relevant issue here is that the field the 2nd argument points to isn't being filled in by wolfSSL, but it will be filled in by OpenSSL.

[anhu]

#9414 will resolve the segfault; note it is a work in progress. Regarding the build errors, I've inspected the first one and its valid. `node is never set which is odd.

@SparkiDev , can you have a look at the build errors in @mandree 's post where he specifies the version of his compiler is

[g]cc (GCC) 15.2.1 20251022 (Red Hat 15.2.1-3) on Fedora Linux 42 x86_64):

[anhu]

I've abandoned #9414 in favour of #9416 .