lastpass / lastpass-cli

LastPass command line interface tool
GNU General Public License v2.0
2.86k stars 290 forks source link

segmentation fault attempting to login on OSX (10.8.5) #50

Closed acyuta108 closed 9 years ago

acyuta108 commented 9 years ago

[1] 16677 segmentation fault lpass login MY_USERNAME

I attempted with all the flags as well.

OSX 10.8.5 Installed with homebrew (0.9.5) Tested in iTerm, Terminal. Tested in zsh/sh/bash

bcopeland commented 9 years ago

Are you handy enough with gdb that you can get a backtrace? I can give instructions if needed. (Please don't post/send a core file, it might have sensitive info in it.)

You'll probably need to remove the contents of process_disable_ptrace() function.

nickjwebb commented 9 years ago

I'll try running gdb on it, it crashes on both of my macs as well, both running 10.8.5.

nickjwebb commented 9 years ago

Here is what I get with gdb, @bcopeland let me know if there are other flags I should provide... as a sysadmin my gdb skills are pretty limited:

(gdb) run login user@domain.com
Starting program: /usr/local/bin/lpass login user@domain.com

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000009
0x00000001000f028d in sk_free ()

Also, the return code is 139, and this is posted to the console (when running outside gdb):

Segmentation fault: 11
bcopeland commented 9 years ago

On Sat, Nov 15, 2014 at 05:04:56PM -0800, nickjwebb wrote:

Here is what I get with gdb, @bcopeland let me know if there are other flags I should provide... as a sysadmin my gdb skills are pretty limited:

(gdb) run login user@domain.com
Starting program: /usr/local/bin/lpass login user@domain.com

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000009
0x00000001000f028d in sk_free ()

After this happens, type:

(gdb) bt

and paste the output.

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

nickjwebb commented 9 years ago

@bcopeland here you go:

(gdb) bt
#0  0x00000001000f028d in sk_free ()
#1  0x00000001000723ea in int_free_ex_data ()
#2  0x00000001001263e5 in X509_STORE_free ()
#3  0x000000010003cdbb in SSL_CTX_set_cert_store ()
#4  0x0000000100009c43 in _mh_execute_header ()
bcopeland commented 9 years ago

Ok, so we are calling SSL_CTX_set_cert_store to pin the thawte cert, SSL_CTX_set_cert_store tries to free the existing X509_STORE object and crashes. I don't see anything obviously wrong with what we are doing here -- we do X509_free() the cert right after it is added but according to at least http://sourceforge.net/p/curl/bugs/1368/ that is the right thing to do.

Are there any updates to libcurl or openssl on your platform that you are missing?

What if you comment out the X509_free(cert); on line 93 of http.c, still crashy?

nickjwebb commented 9 years ago

Hi @bcopeland ,

Good thought on outdated stuff. This is an older "brew" base install, so I tried this:

# brew outdated
curl (7.28.1, 7.38.0 < 7.39.0)
gmp (5.0.5 < 6.0.0a)
gnutls (3.1.6 < 3.3.10)
jq (1.1 < 1.4)
libffi (3.0.11 < 3.0.13)
libgcrypt (1.5.0 < 1.6.2)
libgpg-error (1.10 < 1.17)
libtasn1 (3.2 < 4.2)
lzo (2.06 < 2.08)
mercurial (2.4.2 < 3.2.1)
nettle (2.5 < 2.7.1)
openvpn (2.3.2 < 2.3.4_1)
ossp-uuid (1.6.2 < 1.6.2_1)
p11-kit (0.14 < 0.18.4)
pcre (8.32 < 8.36)
pinentry (0.8.4 < 0.9.0)
postgresql (9.2.2 < 9.3.5_1)
readline (6.2.4 < 6.3.8)
wget (1.14 < 1.16)
xz (5.0.4 < 5.0.7)

Looks pretty old, including curl.

# brew install `brew outdated`

Unfortunately it still fails. I'm trying to get my environment setup to do a manual build, then I'll try commenting out line 93 of http.c.

Thanks.

nickjwebb commented 9 years ago

@bcopeland ,

Success! Commenting out line 93 of http.c fixes it.

                //X509_free(cert);

Nick

nickjwebb commented 9 years ago

Of course, doing anything else in the app still crashes due to a similar issue.

(gdb) run show --username "myapp"
Starting program: /usr/local/bin/lpass show --username "myapp"
Reading symbols for shared libraries +++++.................................................... done
Reading symbols for shared libraries ....................... done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000009
0x00000001000f128d in sk_free ()
(gdb) bt
#0  0x00000001000f128d in sk_free ()
#1  0x00000001000733ea in int_free_ex_data ()
#2  0x00000001001273e5 in X509_STORE_free ()
#3  0x000000010003ddbb in SSL_CTX_set_cert_store ()
#4  0x000000010000a181 in _mh_execute_header ()
nickjwebb commented 9 years ago

Hmm, I'm guessing this is only an issue on 10.8.x, maybe even just 10.8.5? If so, perhaps I should just upgrade to 10.9 / 10.10? I can do at least the former on one workstation, but my MBA is so old it's really not a great option (2011).

bcopeland commented 9 years ago

Did you get a chance to test 10.9 or better?

nickjwebb commented 9 years ago

@bcopeland yes, I'm on mavericks now and it is not an issue. This seems specific to 10.8.x, or maybe even just 10.8.5.

bcopeland commented 9 years ago

Ok - I think I'm going to consider this a third-party library issue, and close it as such, unless someone can point to a bug in how we're using SSL_CTX_set_cert_store().

nickjwebb commented 9 years ago

Thanks @bcopeland for looking at this! Most folks aren't on 10.8 anymore, should be fairly safe to close.