Bug#985820: python3-cryptography: Core dump in buster openssl binding
On Fri, Apr 09, 2021 at 11:34:54AM +0200, Markus Demleitner wrote: > Since this appears to be a known problem, there's reason to hope > it will go away when moving to bullseye, disabling https upgrading Well, it didn't, and I finally wanted to have https on that service, and so I had another look. It turns out that the twisted bug https://twistedmatrix.com/trac/ticket/9764 now has a bit more information. It is still somewhat unfulfilling, as nobody seems to want to work out where the invalid free() comes from, but at least there's a recipe to work around the bug. Me, I'm disabling session caching for now. Twisted seems to do the same thing. Since there *is* a severe, potentially exploitable problem with session caching, perhaps this ought to be the default in python3-openssl? I'd be ok with closing this bug, anyway, as I'd say it's rather clearly not python3-cryptography's own bug.
Bug#985820: python3-cryptography: Core dump in buster openssl binding
Hi Bernhard, Thanks for looking into this. On Thu, Apr 08, 2021 at 05:07:43PM +0200, Bernhard Übelacker wrote: > I found following ticket [2] that shows in later entries > similarities to the given backtrace. Yes, this looks pretty much like what I'm seeing (assuming Glyph's speculation it could be related to python2.7 is wrong, as this is on python3; but I'm going with openssl as the central culprit). > Further running the server with valgrind might show something > related, if the crash happens there too. Since this appears to be a known problem, there's reason to hope it will go away when moving to bullseye, disabling https upgrading made the crashes disappear, and I can live with http for this particular service, I think at this point I'm willing to risk something that feels rather exploitable for another few weeks. These considerations would change if others were seriously concerned; given the twisted ticket has indications on how to trigger the bug outside of production, I might try to organise a windows client to trigger it on a development system. Thanks, Markus
Bug#985820: python3-cryptography: Core dump in buster openssl binding
Hello Markus, I tried to fill in the symbol information that were missing in the above backtrace by using the available dbgsym packages python3-cryptography-dbgsym and libssl1.1-dbgsym. With these installed your gdb would show line information too [3]. I found following ticket [2] that shows in later entries similarities to the given backtrace. Further running the server with valgrind might show something related, if the crash happens there too. Kind regards, Bernhard [1] ... #4 0x...42c in _int_free at malloc.c:4165 #5 0x...9be in SSL_SESSION_free at ../ssl/ssl_sess.c:765 #6 0x...c8c in doall_util_fn at ../crypto/lhash/lhash.c:196 #7 0x...f57 in lh_SSL_SESSION_doall_TIMEOUT_PARAM at ../ssl/ssl_sess.c:1082 #8 0x...4d3 in tls_finish_handshake at ../ssl/statem/statem_lib.c:1075 #9 0x...e3e in state_machine / write_state_machine at ../ssl/statem/statem.c:810 #10 0x...f34 in SSL_do_handshake at ../ssl/ssl_lib.c:3607 #11 0x...71c in _cffi_f_SSL_do_handshake at build/temp.linux-amd64-3.7/_openssl.c:38289 ... [2] https://twistedmatrix.com/trac/ticket/9764 [3] https://wiki.debian.org/HowToGetABacktrace
Bug#985820: python3-cryptography: Core dump in buster openssl binding
Package: python3-cryptography Version: 2.6.1-3+deb10u2 Severity: normal Tags: security A long-running, twisted-based server occasionally (days to weeks) gets aborted when processing HTTPS requests. Here's a basic core dump from an abort: #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7f604e0d2535 in __GI_abort () at abort.c:79 #2 0x7f604e129508 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f604e23428d "%s\n") at ../sysdeps/posix/libc_fatal.c:181 #3 0x7f604e12fc1a in malloc_printerr ( str=str@entry=0x7f604e23243b "free(): invalid pointer") at malloc.c:5341 #4 0x7f604e13142c in _int_free (av=, p=, have_lock=) at malloc.c:4165 #5 0x7f604d77a9be in SSL_SESSION_free () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1 #6 0x7f604d5ddc8c in OPENSSL_LH_doall_arg () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #7 0x7f604d77bf57 in SSL_CTX_flush_sessions () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1 #8 0x7f604d7924d3 in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1 #9 0x7f604d787e3e in ?? () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1 #10 0x7f604d773f34 in SSL_do_handshake () from /usr/lib/x86_64-linux-gnu/libssl.so.1.1 #11 0x7f604d12971c in ?? () from /usr/lib/python3/dist-packages/cryptography/hazmat/bindings/_openssl.abi3.so #12 0x005ccba1 in _PyMethodDef_RawFastCallKeywords () This is about all I know at this point. I've not yet managed to trigger this on a development system. On the operational system, I can live with having a watchdog restart the service when it gets aborted, so I could limp on until bullseye here. On the other hand, an invalid free in openssl sounds a bit unnerving, and so I thought I'd report this and offer to at least install debug packages and look more closely at the problem (disclaimer: as I may have to wait weeks until I'll get another abort, responses may be slow). -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8), LANGUAGE=en_US (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages python3-cryptography depends on: ii libc62.28-10 ii libssl1.11.1.1d-0+deb10u5 ii python3 3.7.3-1 ii python3-asn1crypto 0.24.0-1 ii python3-cffi-backend [python3-cffi-backend-api-min] 1.12.2-1 pn python3-cffi-backend-api-max ii python3-six 1.12.0-1 python3-cryptography recommends no packages. Versions of packages python3-cryptography suggests: pn python-cryptography-doc pn python3-cryptography-vectors -- no debconf information