freebsd-pefs / pefs

PEFS - stacked cryptographic file system for FreeBSD
http://pefs.io/
76 stars 15 forks source link

pam_pefs.so crashing sshd (signal 11) #22

Closed rustyx closed 9 years ago

rustyx commented 10 years ago

I'm trying to encrypt my home directory, it is working with a local login (/etc/pam.d/system) and FTP but not with sshd.

OS: FreeBSD 9.1-RELEASE i386

My /etc/pam.d/sshd looks like this:

# auth
auth            sufficient      pam_opie.so             no_warn no_fake_prompts
auth            requisite       pam_opieaccess.so       no_warn allow_local
#auth           sufficient      pam_krb5.so             no_warn try_first_pass
#auth           sufficient      pam_ssh.so              no_warn try_first_pass
auth            sufficient      /usr/local/lib/pam_pefs.so      try_first_pass delkeys
auth            required        pam_unix.so             no_warn try_first_pass

# account
account         required        pam_nologin.so
#account        required        pam_krb5.so
account         required        pam_login_access.so
account         required        pam_unix.so

# session
#session        optional        pam_ssh.so              want_agent
session         optional        /usr/local/lib/pam_pefs.so      delkeys
session         required        pam_permit.so

# password
#password       sufficient      pam_krb5.so             no_warn try_first_pass
password        required        pam_unix.so             no_warn try_first_pass

As soon as I enter my password, the session disconnects, and the following is logged:

Aug 19 22:55:27 v kernel: pid 984 (sshd), uid 1002: exited on signal 11
rustyx commented 10 years ago

Just tried in FreeBSD 10.0 amd64, same crash with pefs-kmod built from ports, however pefs-kmod package doesn't crash but also doesn't work (the key never matches).

The ports version crashes at:

#0  0x284b346a in memcpy () from /lib/libc.so.7
#1  0x2832fd03 in SHA512_Update () from /lib/libcrypto.so.6
#2  0x286bfc65 in hmac_init () from /usr/local/lib/pam_pefs.so.5
#3  0x286bf06b in pefs_key_generate () from /usr/local/lib/pam_pefs.so.5
#4  0x286c027b in pam_sm_authenticate () from /usr/local/lib/pam_pefs.so.5
#5  0x2811d6a4 in openpam_dispatch () from /usr/lib/libpam.so.5
glk commented 10 years ago

Problem is two-fold:

With 7b1cacb286c4bc93a835aa1f0b7bf7594670ff25 ssh should accept the password but won't add key to the file system. Could you please verify that ssh password login part is fixed.

In case it helps I'm using the following configuration for ssh:

rustyx commented 10 years ago

The master snapshot of today indeed didn't crash but just like the packages version it generated a wrong key from a correct password. I traced the issue down to a broken bzero() implementation in sshd which overruns the supplied size in SHA512_Init() and damages hmac_sha512_ctx.opad which in turn results in a wrong digest output. I was able to work around it by replacing bzero with memset.

I don't know where the broken bzero() comes from, but it's broken on i386 as well as amd64.

===EDIT=== This issue seems to be resolved in 10-stable.

Anyway, as you mentioned this only solves the first half of the issue. The filesystem was still not decrypted on ssh login.

rustyx commented 10 years ago

I was able to get sshd from the security/openssh port to work by enabling the "unsupported PAM pthread hack" with this patch:

patch-pam-pthread-hack

Drop it into /usr/ports/security/openssh-portable/files and then install the openssh port normally.

The good thing about this you can at the same time enable high-performance features such as HPN and AES_THREADED.

It would be nice to adjust the openssh port to make this feature configurable at build time.

glk commented 10 years ago

Unless compiled with -fno-builtin both clang and gcc will replace bzero with memset. I doubt bzero is broken..

rustyx commented 10 years ago

ok I upgraded to 10-stable and the bzero issue is gone. But I can swear I saw the first bytes of opad being zeroed right after bzero call in SHA512_Init().

Regarding the pam_set_data, there are various workarounds available as a patch to sshd, it is also possible to use shared memory like krb5 does, though that might become difficult in a sandboxed environment.

Anyway, I guess this particular issue can be closed since the crash is already fixed in master.