search

trustcrypto / python-onlykey

The OnlyKey Python Command-Line Utility is a command line tool targeted towards more advanced users. This can be used for configuration and testing.
https://docs.crp.to/command-line.html
49 stars 23 forks source link

onlykey-cli segfaults in libusb-1.0.so.0.2.0 at the end of execution #44

Open nkichukov opened 3 years ago

nkichukov commented 3 years ago

Hello team,

I am running onlykey-cli version 1.2.4 here under python 3.8 on GNU/Gentoo Linux amd64 kernel 5.11.7.

Execution of commands work, however, instead of graceful exit I am getting segmentation faults in the end. Seems like they are related to libusb.so:

[Thu Mar 25 17:07:52 2021] onlykey-cli[14300]: segfault at 220 ip 00007fc7df35abfb sp 00007fc7db414d30 error 4 in libusb-1.0.so.0.2.0[7fc7df354000+e000]
[Thu Mar 25 17:07:52 2021] Code: 56 41 55 41 54 55 48 89 fd 53 48 89 f3 48 83 ec 20 64 48 8b 04 25 28 00 00 00 48 89 44 24 18 31 c0 48 85 ff 0f 84 55 01 00 00 <8b> 85 20 02 00 00 45 31 e4 85 c0 78 28 48 8b 44 24 18 64 48 2b 04
[Thu Mar 25 17:14:02 2021] onlykey-cli[14904]: segfault at 220 ip 00007ffb79e10bfb sp 00007ffb75ecad30 error 4 in libusb-1.0.so.0.2.0[7ffb79e0a000+e000]
[Thu Mar 25 17:14:02 2021] Code: 56 41 55 41 54 55 48 89 fd 53 48 89 f3 48 83 ec 20 64 48 8b 04 25 28 00 00 00 48 89 44 24 18 31 c0 48 85 ff 0f 84 55 01 00 00 <8b> 85 20 02 00 00 45 31 e4 85 c0 78 28 48 8b 44 24 18 64 48 2b 04

versions of additional packages that are used by onlykey-cli: dev-libs/libusb-1.0.23-r1:1 sys-auth/solo-python-0.0.27:0 dev-libs/hidapi-0.10.1:0 dev-python/hidapi-0.10.1_p20210303:0 dev-python/aenum-2.2.4:0 dev-python/six-1.15.0-r1:0 dev-python/prompt_toolkit-3.0.16:0

I have checked a 'strace -f' execution to try to figure out what goes wrong but nothing obvious in there. Any pointers?

Here is example execution with the segfault failure in the end:

$ onlykey-cli version
OnlyKey CLI v1.2.4
Segmentation fault
nkichukov commented 3 years ago

I've removed solo-python and installed onlykey-solo-python instead [main] branch. No difference.

The GDB output is as follows:

(gdb) run /usr/bin/onlykey-cli fwversion
Starting program: /usr/bin/python3.8 /usr/bin/onlykey-cli fwversion
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Detaching after fork from child process 3966]
[New Thread 0x7ffff3527640 (LWP 3968)]
[New Thread 0x7ffff2d26640 (LWP 3969)]
v2.1.0-prodc
[Thread 0x7ffff3527640 (LWP 3968) exited]

Thread 3 "python3.8" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff2d26640 (LWP 3969)]
0x00007ffff6c6bbfb in libusb_get_next_timeout () from /lib64/libusb-1.0.so.0
onlykey commented 3 years ago

We recommend to install OnlyKey CLI via the docs here, $ pip3 install onlykey

https://docs.crp.to/command-line.html#linuxbsd-install-with-dependencies

nkichukov commented 3 years ago

Thanks, but I am running a source based distribution here, this deviates heavily from the way we manage our packages in Gentoo, thus I walk the next mile to make it work as close to the Gentoo philosophy as possible.

Now, if I upgrade libusb to: dev-libs/libusb-1.0.24-r1:1

The failure has changed a bit, instead of segmentation fault, now I get Abort:

$ onlykey-cli fwversion
v2.1.0-prodc
python3.8: /var/tmp/portage/dev-libs/libusb-1.0.24-r1/work/libusb-1.0.24/libusb/os/threads_posix.h:58: usbi_mutex_destroy: Assertion `pthread_mutex_destroy(mutex) == 0' failed.
Aborted

Which is way more graceful than before. I have also upgraded: dev-libs/hidapi-9999:0 dev-python/hidapi-9999:0

to the latest version from their git repositories, master branches.

However, if I run the utility without any parameters, ie:

$ onlykey-cli 
OnlyKey CLI v1.2.4
Control-D to exit.

OnlyKey> fwversion

v2.1.0-prodc

OnlyKey>                                                                                                                                                                                                                              

Bye!

There are no issues, as it seems.

What I have observed is, something very similar to the challenge response bug of keepassxc from before, which unbinds one of the required rawhid or just hid devices and then, perhaps because of the Abort or anything else it does not reattach the HID device back to the kernel. So the Onlykey-App thinks that there is no onlykey connected, where in reality it is.

To workaround this, I have re-enabled my additional udev rules to readd the device after some time and then the Onlykey-App picks it up successfully, something similar to: echo '1-6.2:1.2' > /sys/bus/usb/drivers/usbhid/bind

If this is hard to troubleshoot and you think there is no point in it, I am happy to close as I have a workaround and I have automated the 'settime'.

Thanks

nkichukov commented 3 years ago

Hi Tim, I have recompiled libusb, python, cython-hidapi, hidapi with debug symbols enabled and was able to collect debug output, including prints from libusb itself, a backtrace and full backtrace. It seems like the 'abort' is generated because the application has left some devices open when exiting the session.

See attached log file. onlykey-cli-debug-output.txt

Let me know if you need anything else to troubleshoot this further. Cheers, -N

onlykey commented 3 years ago

Thanks for the information, I will check the source and see if there are any cases where we open a device but do not close it.

onlykey commented 3 years ago

@nkichukov Can you test this fix? It should now in all cases at exit close USB in case program exits with device open.

$ git clone https://github.com/trustcrypto/python-onlykey -b fix-close-usb
$ cd python-onlykey
$ pip3 install .
nkichukov commented 3 years ago

It works, thank you Tim!

halt-avmc commented 2 years ago

I have very similar symptoms with onlykey-cli v1.2.6 OS: Ubuntu MATE

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.3 LTS
Release:    20.04
Codename:   focal

It works in "interactive mode", i.e. by simply running onlykey-cli in console.

$ onlykey-cli 
OnlyKey CLI v1.2.6
Control-D to exit.

OnlyKey> version

OnlyKey CLI v1.2.6

OnlyKey>                                                                                                                                                                                                                                     

Bye!

But segfaults when executing with arguments. For example

$ onlykey-cli version
OnlyKey CLI v1.2.6
Segmentation fault (core dumped)

Not sure if this is also because of libusb as mentioned earlier in the very beginning topic (because I don't know how to check/verify this) And unfortunately I can not try workaround from this answer https://github.com/trustcrypto/python-onlykey/issues/44#issuecomment-933813039 because git says fatal: Remote branch fix-close-usb not found in upstream origin Looks like there is no more such a git-branch

Not to mention app was installed as was said in here https://docs.crp.to/command-line.html#linuxbsd-install-with-dependencies

onlykey commented 2 years ago

@halt-avmc Can you try installing from release here - https://github.com/trustcrypto/python-onlykey/releases/tag/v1.2.8

halt-avmc commented 2 years ago

@halt-avmc Can you try installing from release here - https://github.com/trustcrypto/python-onlykey/releases/tag/v1.2.8

Looks like it works, no more segfaults. Thanks!

I have to admit I am not that python guru, so my "installation" was like simply download src archive, unpack it and replace "onlykey" dir under my local python's site-packages. That are only this files:

onlykey/__init__.py
onlykey/client.py
onlykey/cli.py

I am pretty sure this is not the right way to update. First I tried to pip3 uninstall onlykey and install it again, but it installed the old version onlykey v1.2.6 instead of v.1.2.8 So that is my kind of workaround.

UPD: found more correct way of updating: pip3 install git+https://github.com/trustcrypto/python-onlykey.git@v1.2.8