VERBOSE Root directory: /xxxxxxxxxxxxxxxxxxxxxxxx/ [main.cpp:686] VERBOSE Fuse arguments: (daemon) (threaded) (keyCheck) encfs /xxxxxxxxxxxxxxxxxxxxxxx/ -o use_ino -o default_permissions [main.cpp:687] VERBOSE found new serialization format [FileUtils.cpp:299] VERBOSE subVersion = 20100713 [FileUtils.cpp:313] VERBOSE checking if ssl/aes(3:0:2) implements ssl/blowfish(3:0) [Interface.cpp:103] VERBOSE checking if ssl/blowfish(3:0:2) implements ssl/blowfish(3:0) [Interface.cpp:103] VERBOSE allocated cipher ssl/blowfish, keySize 32, ivlength 8 [SSL_Cipher.cpp:395] VERBOSE useStdin: 0 [FileUtils.cpp:1660] EncFS-Passwort: VERBOSE checking if ssl/aes(3:0:2) implements ssl/blowfish(3:0) [Interface.cpp:103] VERBOSE checking if ssl/blowfish(3:0:2) implements ssl/blowfish(3:0) [Interface.cpp:103] VERBOSE allocated cipher ssl/blowfish, keySize 32, ivlength 8 [SSL_Cipher.cpp:395] dmesg: [Fr Jul 1 20:49:01 2022] encfs[3068]: segfault at 78 ip 00007f1e98b10fe4 sp 00007ffdea437260 error 4 in libcrypto.so.3[7f1e989cf000+279000] [Fr Jul 1 20:49:01 2022] Code: 84 00 00 00 00 00 41 54 41 89 f4 55 48 89 fd 48 81 ec a8 00 00 00 64 48 8b 04 25 28 00 00 00 48 89 84 24 98 00 00 00 48 8b 07 <48> 83 78 78 00 0f 84 e1 00 00 00 66 0f ef c0 48 63 c6 48 89 44 24 No mount is done and error code is 139. Without -v, no output (except of password) is done.
Hello Klaus,
I tried to have a look at the dmesg line you supplied.
That leads to evp_enc.c, line 985.
That function shows up in a maybe similar crash in freerdp.
There it was caused by using some legacy algorithms, which seem
got disabled in libssl3.
Got this encrypted directory created with some older encfs version, some time ago?
If yes, can you remember which Debian release this might have been?
Kind regards,
Bernhard
(gdb) pipe info proc mapping | grep crypto
0x7f9795000000 0x7f97950c4000 0xc4000 0x0 r--p /usr/lib/x86_64-linux-gnu/libcrypto.so.3
0x7f97950c4000 0x7f979533d000 0x279000 0xc4000 r-xp /usr/lib/x86_64-linux-gnu/libcrypto.so.3
0x7f979533d000 0x7f979541b000 0xde000 0x33d000 r--p /usr/lib/x86_64-linux-gnu/libcrypto.so.3
0x7f979541b000 0x7f979547c000 0x61000 0x41b000 r--p /usr/lib/x86_64-linux-gnu/libcrypto.so.3
0x7f979547c000 0x7f979547f000 0x3000 0x47c000 rw-p /usr/lib/x86_64-linux-gnu/libcrypto.so.3
(gdb) find /b 0x7f97950c4000, 0x7f979533d000, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x41, 0x54, 0x41, 0x89, 0xf4, 0x55, 0x48, 0x89, 0xfd, 0x48, 0x81, 0xec, 0xa8, 0x00, 0x00, 0x00, 0x64, 0x48, 0x8b, 0x04, 0x25, 0x28, 0x00, 0x00, 0x00, 0x48, 0x89, 0x84, 0x24, 0x98, 0x00, 0x00, 0x00, 0x48, 0x8b, 0x07, 0x48, 0x83, 0x78, 0x78, 0x00, 0x0f, 0x84, 0xe1, 0x00, 0x00, 0x00, 0x66, 0x0f, 0xef, 0xc0, 0x48, 0x63, 0xc6, 0x48, 0x89, 0x44, 0x24
0x7f9795205fba
1 pattern found.
(gdb) b * (0x7f9795205fba + 42)
Breakpoint 1 at 0x7f9795205fe4: file ../crypto/evp/evp_enc.c, line 985.
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y 0x00007f9795205fe4 in EVP_CIPHER_CTX_set_key_length at ../crypto/evp/evp_enc.c:985
(gdb) disassemble EVP_CIPHER_CTX_set_key_length
Dump of assembler code for function EVP_CIPHER_CTX_set_key_length:
0x00007f9795205fc0 <+0>: push %r12
0x00007f9795205fc2 <+2>: mov %esi,%r12d
0x00007f9795205fc5 <+5>: push %rbp
0x00007f9795205fc6 <+6>: mov %rdi,%rbp
0x00007f9795205fc9 <+9>: sub $0xa8,%rsp
0x00007f9795205fd0 <+16>: mov %fs:0x28,%rax
0x00007f9795205fd9 <+25>: mov %rax,0x98(%rsp)
0x00007f9795205fe1 <+33>: mov (%rdi),%rax
0x00007f9795205fe4 <+36>: cmpq $0x0,0x78(%rax) <<<<<<<
0x00007f9795205fe9 <+41>: je 0x7f97952060d0 <EVP_CIPHER_CTX_set_key_length+272>
0x00007f9795205fef <+47>: pxor %xmm0,%xmm0
0x00007f9795205ff3 <+51>: movslq %esi,%rax
0x00007f9795205ff6 <+54>: mov %rax,0x38(%rsp)
.
https://sources.debian.org/src/openssl/3.0.4-2/crypto/evp/evp_enc.c/#L985
985 if (c->cipher->prov != NULL) {
Similar to https://github.com/openssl/openssl/issues/14392 ?
Hi Bernhard,
Am So den 17. Jul 2022 um 19:04 schrieb Bernhard Übelacker:
Well, it was for sure debian sid. But it was surely more than 10 years
ago.
The Header of .encfs6.xml suggest something around 2010:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE boost_serialization>
<boost_serialization signature="serialization::archive" version="7">
<cfg class_id="0" tracking_level="0" version="20">
<version>20100713</version>
<creator>EncFS 1.9.5</creator>
<cipherAlg class_id="1" tracking_level="0" version="0">
<name>ssl/blowfish</name>
<major>3</major>
<minor>0</minor>
</cipherAlg>
<nameAlg>
<name>nameio/null</name>
<major>1</major>
<minor>0</minor>
</nameAlg>
<keySize>256</keySize>
<blockSize>1024</blockSize>
...
Gruß
Klaus
Hello Klaus, thanks for the fast response. Now I could reproduce the crash even when creating a new encrypted directory, just by selecting the blowfish algorithm [1]. Before I just tested with default parameters. Based on the patch from the before mentioned freerdp issue, the following diff seems also to avoid the crash [2]. And upstream seems to track this in following issue: https://github.com/vgough/encfs/issues/651 There is also another workaround by modifying the openssl configuration if the package rebuild is not wanted. Kind regards, Bernhard [1] (gdb) bt #0 0x00007f4c8b605fe4 in EVP_CIPHER_CTX_set_key_length (c=0x55db8e06c8b0, keylen=32) at ../crypto/evp/evp_enc.c:985 #1 0x00007f4c8bf8a88a in encfs::initKey (key=std::shared_ptr<encfs::SSLKey> (use count 1, weak count 0) = {...}, _blockCipher=0x7f4c8b860d00 <bf_cbc>, _streamCipher=0x7f4c8b860c00 <bf_cfb64>, _keySize=32) at /usr/include/c++/11/bits/shared_ptr_base.h:1295 #2 0x00007f4c8bf8bdd4 in encfs::SSL_Cipher::newRandomKey (this=0x55db8e06b770) at ./encfs/SSL_Cipher.cpp:506 #3 0x00007f4c8bf82e90 in encfs::createV6Config (ctx=0x55db8e06a590, opts=std::shared_ptr<encfs::EncFS_Opts> (use count 1, weak count 0) = {...}) at ./encfs/FileUtils.cpp:1220 #4 0x00007f4c8bf858c6 in encfs::initFS (ctx=ctx@entry=0x55db8e06a590, opts=std::shared_ptr<encfs::EncFS_Opts> (use count 1, weak count 0) = {...}) at ./encfs/FileUtils.cpp:1728 #5 0x000055db8c62eb22 in main (argc=<optimized out>, argv=<optimized out>) at ./encfs/main.cpp:741 [2] --- encfs-1.9.5.orig/encfs/SSL_Cipher.cpp +++ encfs-1.9.5/encfs/SSL_Cipher.cpp @@ -25,6 +25,7 @@ #include <openssl/evp.h> #include <openssl/hmac.h> #include <openssl/ossl_typ.h> +#include <openssl/provider.h> #include <openssl/rand.h> #include <pthread.h> #include <string> @@ -355,6 +356,9 @@ inline unsigned char *IVData(const std:: void initKey(const std::shared_ptr<SSLKey> &key, const EVP_CIPHER *_blockCipher, const EVP_CIPHER *_streamCipher, int _keySize) { Lock lock(key->mutex); + + OSSL_PROVIDER_load(NULL, "legacy"); + // initialize the cipher context once so that we don't have to do it for // every block.. EVP_EncryptInit_ex(key->block_enc, _blockCipher, nullptr, nullptr, nullptr);
Hi Bernhard, Am Mo den 18. Jul 2022 um 10:50 schrieb Bernhard Übelacker: I read that and tried the config setting in /etc/ssl/openssl.cnf. But it didn't work for me. I get the same segfault. I had to also add `providers = provider_sect` in openssl_init section. to let it work. If that fixes the bug, it would be great to be applied. However, I concider that a bug in openssl as it would need random changes in many other software, I believe. Gruß Klaus
Am Mo den 18. Jul 2022 um 10:50 schrieb Bernhard Übelacker: If I read the documentation correct, that will ONLY load the legacy provider. So you have to also load the default provider explicitly. Gruß Klaus
After upgrading to bookworm, encfs segfaults for me when trying to open encrypted directories created a long time ago. The solution in https://askubuntu.com/questions/1405656/encfs-segfault-in-version-22-04 worked, which is to edit /etc/ssl/opensslf.conf and add [openssl_init] providers = provider_sect # List of providers to load [provider_sect] default = default_sect legacy = legacy_sect [default_sect] activate = 1 [legacy_sect] activate = 1 It would be great to document this in NEWS.Debian as this worked fine in bullseye enfsctl info says: Version 5 configuration; created by EncFS 1.2.5 (revision 20040813) Filesystem cipher: "ssl/blowfish", version 2:1:1 (using 3:0:2)