Re: Application segfaults after upgrade from 3.0.11 to 3.0.13

Please update to 3.0.14. The change that most likely caused this
regression for you was reverted in that release by the following pull
request: https://github.com/openssl/openssl/pull/23063

Tomas Mraz, OpenSSL

On Wed, 2024-07-17 at 08:47 +0300, Victor Wagner wrote:
> On Tue, 16 Jul 2024 14:40:59 -0400
> Neil Horman <[email protected]> wrote:
> 
> > Can you post the stack trace of the segv here?
> 
> Sure:
> 
> Core was generated by `osslsigncode sign -pkcs11module
> /usr/lib/librtpkcs11ecp.so -pkcs11cert pkcs11:o'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x00007fe9e87862d2 in pkcs11_getattr_var (
> --Type <RET> for more, q to quit, c to continue without paging--
>     ctx=ctx@entry=0x9d33983bac913f76, session=session@entry=1,
>     object=object@entry=3292546510, type=type@entry=288,
>     value=value@entry=0x0, size=size@entry=0x7ffe166572f0)
>     at ./src/p11_attr.c:46
> 46      ./src/p11_attr.c: No such file or directory.
> (gdb) bt
> #0  0x00007fe9e87862d2 in pkcs11_getattr_var (
>     ctx=ctx@entry=0x9d33983bac913f76, session=session@entry=1,
>     object=object@entry=3292546510, type=type@entry=288,
>     value=value@entry=0x0, size=size@entry=0x7ffe166572f0)
>     at ./src/p11_attr.c:46
> #1  0x00007fe9e87863cc in pkcs11_getattr_alloc (
>     ctx=ctx@entry=0x9d33983bac913f76, session=1,
>     object=object@entry=3292546510, type=type@entry=288,
>     value=value@entry=0x7ffe16657348, size=size@entry=0x7ffe16657350)
>     at ./src/p11_attr.c:66
> #2  0x00007fe9e87864e0 in pkcs11_getattr_bn
> (ctx=ctx@entry=0x9d33983bac913f76,
>     session=<optimized out>, object=object@entry=3292546510,
>     type=type@entry=288, bn=bn@entry=0x7ffe16657380) at
> ./src/p11_attr.c:92
> #3  0x00007fe9e8788d77 in pkcs11_get_rsa (key=0x55c5c9711950)
>     at ./src/p11_rsa.c:197
> #4  0x00007fe9e87896d3 in pkcs11_get_evp_key_rsa (key=0x55c5c9711950)
>     at ./src/p11_rsa.c:265
> #5  0x00007fe9e8788222 in pkcs11_get_key
> (key0=key0@entry=0x55c5c9711950,
>     object_class=<optimized out>) at ./src/p11_key.c:450
> #6  0x00007fe9e878933f in pkcs11_rsa (key=key@entry=0x55c5c9711950)
>     at ./src/p11_rsa.c:34
> #7  pkcs11_get_key_size (key=key@entry=0x55c5c9711950) at
> ./src/p11_rsa.c:332
> #8  0x00007fe9e87893c4 in pkcs11_private_encrypt (flen=51,
>     from=0x55c5c96e9e60 "010\r\006\t`\206H\001e\003\004\002\001\005",
>     to=0x55c5c969f8f0 "\377\3613\225\300U", key=0x55c5c9711950,
> padding=1)
>     at ./src/p11_rsa.c:91
> #9  0x00007fe9e847f9bd in RSA_sign (type=<optimized out>,
>     m=m@entry=0x7ffe166578b0
> "\266\307O\326\361\367\033\262\357\t,U\220\032\002E\207\342o
> \352e̝\350\257\342o/\255", <incomplete sequence \343\275>,
>     m_len=m_len@entry=32,
>     sigret=sigret@entry=0x55c5c969f8f0 "\377\3613\225\300U",
>     siglen=siglen@entry=0x7ffe16657844, rsa=rsa@entry=0x55c5c9711ac0)
>     at ../crypto/rsa/rsa_sign.c:309
> #10 0x00007fe9e847e154 in pkey_rsa_sign (ctx=0x55c5c96bc0e0,
>     sig=0x55c5c969f8f0 "\377\3613\225\300U", siglen=0x7ffe16657950,
>     tbs=0x7ffe166578b0
> "\266\307O\326\361\367\033\262\357\t,U\220\032\002E\207\342o
> \352e̝\350\257\342o/\255", <incomplete sequence \343\275>, tbslen=32)
>     at ../crypto/rsa/rsa_pmeth.c:176
> #11 0x00007fe9e841648e in EVP_DigestSignFinal
> (ctx=ctx@entry=0x55c5c96a5a00,
>     sigret=0x55c5c969f8f0 "\377\3613\225\300U",
>     siglen=siglen@entry=0x7ffe16657950) at
> ../crypto/evp/m_sigver.c:560
> #12 0x00007fe9e8460468 in PKCS7_SIGNER_INFO_sign
> (si=si@entry=0x55c5c96a8650)
>     at ../crypto/pkcs7/pk7_doit.c:945
> #13 0x00007fe9e8460702 in do_pkcs7_signed_attrib
> (mctx=0x55c5c96a57d0,
>     si=0x55c5c96a8650) at ../crypto/pkcs7/pk7_doit.c:721
> #14 PKCS7_dataFinal (p7=p7@entry=0x55c5c96f39e0,
> bio=bio@entry=0x55c5c96a5620)
>     at ../crypto/pkcs7/pk7_doit.c:843
> #15 0x000055c5c89f7490 in pkcs7_sign_content
> (p7=p7@entry=0x55c5c96f39e0,
>     data=0x55c5c97089c2
> "04\006\n+\006\001\004\001\2027\002\001\0170&\003\002\a\200\240
> \242\036\200\034", len=105) at ./helpers.c:397
> #16 0x000055c5c89f75b1 in sign_spc_indirect_data_content (
>     p7=p7@entry=0x55c5c96f39e0, content=content@entry=0x55c5c96d5320)
>     at ./helpers.c:280
> #17 0x000055c5c89fcfc9 in pe_pkcs7_signature_new (ctx=<optimized
> out>,
>     hash=0x55c5c96da260) at ./pe.c:407
> #18 0x000055c5c89ee460 in main (argc=<optimized out>, argv=<optimized
> out>)
>     at ./osslsigncode.c:4955
> (gdb) q
> 
> Following debugger output may be also of interest:
> 
> (gdb) p *ctx
> Cannot access memory at address 0x9d33983bac913f76
> (gdb) up 3
> #3  0x00007fe9e8788d77 in pkcs11_get_rsa (key=0x55c5c9711950)
>     at ./src/p11_rsa.c:197
> 197     ./src/p11_rsa.c: No such file or directory.
> (gdb) p *slot
> $1 = {refcnt = 1549571800, ctx = 0x9d33983bac913f76, lock = {__data =
> {
>       __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0,
>       __spins = 0, __elision = 0, __list = {__prev = 0x0, __next =
> 0x0}}, 
>     __size = '\000' <repeats 39 times>, __align = 0}, cond = {__data
> = {
> (gdb) dir /usr/src/debug/libp11-0.4.12
> Source directories searched: /usr/src/debug/libp11-0.4.12:$cdir:$cwd
> (gdb) l 185
> 180      */
> 181     static RSA *pkcs11_get_rsa(PKCS11_OBJECT_private *key)
> 182     {
> 183             CK_OBJECT_CLASS class_public_key = CKO_PUBLIC_KEY;
> 184             PKCS11_SLOT_private *slot = key->slot;
> 185             PKCS11_CTX_private *ctx = slot->ctx;
> 186             PKCS11_OBJECT_private *pubkey;
> 187             PKCS11_TEMPLATE tmpl = {0};
> 188             CK_OBJECT_HANDLE object = key->object;
> 189             CK_SESSION_HANDLE session;
> 
> 
> > 
> > On Tue, Jul 16, 2024 at 12:43 PM Victor Wagner <[email protected]>
> > wrote:
> > 
> > > Hi!
> > > 
> > > I'm using osslsigncode application on Debian 12 system (amd64) to
> > > sign stuff with RSA key stored on hardware token with PKCS11
> > > interface.
> > > 
> > > osslsigncode (https://github.com/mtrojnar/osslsigncode) seems to
> > > be
> > > well-behaved openssl application, which uses digest BIO and PKCS7
> > > API, does no poking into opaque structures etc.
> > > 
> > > Application was compiled from source in February, when openssl
> > > version in Debian was 3.0.11-1~deb12u1
> > > 
> > > Unfortunately, when security update of libssl3 (debian package
> > > for
> > > openssl libraries) version 3.0.13-1~deb12u1 was installed,
> > > osslsigncode begin to crash with SIGSEGV.
> > > 
> > > Quick debugging session shows that application is able to
> > > initialize
> > > token and correctly obtain private key handle and certificate for
> > > it. But when trying to sign, it receives invalid pointer to
> > > PKCS11_CTX_private structure. (segfault happens inside pkcs11.so)
> > > This pointer is contained in PKCS11_SLOT_private structure, which
> > > has refcount field before this pointer, and this field also seems
> > > to be filled with garbage (i expect refcount to be less than 10
> > > in
> > > so small program, which handles just one signature and it is some
> > > 32-bit value with second high order bit set).
> > > 
> > > Downgrade to previous version of openssl libraries fixes the
> > > problem.
> > > 
> > > I suspect that problem is in application, which somehow misuses
> > > openssl API but have no idea how to look for problem. Really, it
> > > seems to to be good idea to track memory writes to PKCS11_SLOT
> > > object, but it is hidden inside so many levels of opaque
> > > structures.
> > > 
> > > I've thought about checking what change in openssl may affect
> > > problem, but don't see anything appropriate in changelog between
> > > 3.0.11 and 3.0.13 (and debian maintainers seems to add nothing
> > > new
> > > over upstream changes).
> > > --
> > >  
> 

-- 
Tomáš Mráz, OpenSSL