Segfaults after every show command, OS X 10.11.4

[adamdicarlo]

Hi, I've tried compiling from source, running from Homebrew, but I always get this exact same crash after running, e.g. lpass show --password 'My Site'. It prints the password, but then the OS X crash window appears.

https://paste.ee/p/pN8Ic (stack traces and such)

As far as I can tell it has something to do with trying to start the agent, given this part of the message:

Application Specific Information:
*** multi-threaded process forked ***
crashed on child side of fork pre-exec

I've tried attaching gdb to it with no success (after doing the whole dance of removing the "don't trace this process" code and code-signing gdb); I think the fact that the crash happens in the child process prevented my gdb session from catching it.

Any ideas on this? Can I help track it down?

[adamdicarlo]

➜  lastpass-cli (master) ✔ brew info openssl
openssl: stable 1.0.2h (bottled) [keg-only]
SSL/TLS cryptography library
https://openssl.org/
/usr/local/Cellar/openssl/1.0.2h (1,691 files, 12M)
[...]

Not sure what other info would help, but happy to provide whatever!

[bcopeland]

On Wed, May 04, 2016 at 11:04:56AM -0700, Adam DiCarlo wrote:

Hi, I've tried compiling from source, running from Homebrew, but I always get this exact same crash after running, e.g. lpass show --password 'My Site'. It prints the password, but then the OS X crash window appears.

https://paste.ee/p/pN8Ic (stack traces and such)

As far as I can tell it has something to do with trying to start the agent, given this part of the message:

Application Specific Information:
*** multi-threaded process forked ***
crashed on child side of fork pre-exec

If the stack trace is to be believed, it rather looks like it is part
of libcurl/openssl on your platform via

http_post_lastpass_v_noexit() -> curl_easy_perform() -> ...

If you trust your network, computer, etc., you might try removing the
key pinning just to remove that as a variable, that is, comment out
this line:

    curl_easy_setopt(curl, CURLOPT_SSL_CTX_FUNCTION, pin_keys);

If it then works, then there's either a bug in our pin_keys function
(though at a quick scan I didn't see one) or a bug in the platform's
openSSL (not completely unlikely, as Apple tries hard to make sure you
use their crypto library instead.)

Bob Copeland %% http://bobcopeland.com/

[adamdicarlo]

thanks for looking at this! I tried commenting out that line in http.c and rebuilding, but I still get the exact same crash. Same when building with libressl homebrew package instead. I also tried commenting out the two prior lines (VERIFYHOST, VERIFYPEER). Same result.

my process is basically:

make clean
LDFLAGS="-L/usr/local/opt/openssl/lib" CPPFLAGS="-I/usr/local/opt/openssl/include -g" make`
./lpass show --password 'xxxxxxxxx'

For kicks I just tried:

brew link --force openssl
make clean
make
./lpass show --password 'xxxxxxxxx'

which yields this (I'm guessing this is really just not how you're supposed to build a package, heh):

lpass(90482,0x7fff7365b000) malloc: *** mach_vm_map(size=4611686018427392000) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
Error: Cannot allocate memory: malloc(4611686018427387929)

¯_(ツ)_/¯

[franzinc]

FWIW, I installed lpass v0.9.0 from macports today (after updating all ports) and it works for me on 10.11.4.

[KimNorgaard]

I get this also with 10.11.6

Crash report here: https://paste.ee/p/7RL8W

lastpass-cli 1.0.0
openssl 1.0.2h_1
curl 7.50.1

[bcopeland]

@KimNorgaard it looks like your version of libcurl is not linked with openssl?

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libdispatch.dylib               0x00007fff93e346d7 _dispatch_queue_push_queue + 463
1   libdispatch.dylib               0x00007fff93e32b06 _dispatch_queue_wakeup_with_qos_slow + 126
2   libcorecrypto.dylib             0x00007fff9ca79ddc ccrng_CommonCrypto_generate + 309
3   libsystem_coretls.dylib         0x00007fff922d8cbf sslRand + 40
4   libsystem_coretls.dylib         0x00007fff922e0b66 SSLEncodeRandom + 62
5   libsystem_coretls.dylib         0x00007fff922e1891 SSLEncodeClientHello + 1321
6   libsystem_coretls.dylib         0x00007fff922df8df SSLPrepareAndQueueMessage + 41
7   libsystem_coretls.dylib         0x00007fff922dddd3 SSLAdvanceHandshake + 196
8   com.apple.security              0x0000000108430a17 SSLHandshakeProceed + 58
9   com.apple.security              0x00000001084309c6 SSLHandshake + 126
10  libcurl.4.dylib                 0x00007fff9a203de3 darwinssl_connect_step2 + 74

[bcopeland]

I think these are all cases of having the wrong curl and/or curl linked against a different openssl that the one the main binary is linked against. I'll close this now under that impression, if anyone can demonstrate that is not the cause, please reopen.