Re: Application segfaults after upgrade from 3.0.11 to 3.0.13

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).
> > --
> >