Crash in fzsftp.exe

[Drake D. Taylor]

As of version 3.13.0 connecting to certain SFTP servers causes fzsftp.exe to crash. All previous versions of FileZilla used to work like a charm with the same servers.

Here's FileZilla's debug log:

Status:	Connecting to 127.0.0.1...
Trace:	Going to execute C:\Program Files\FileZilla FTP Client\fzsftp.exe
Response:	fzSftp started, protocol_version=3
Trace:	CSftpControlSocket::ConnectParseResponse(fzSftp started, protocol_version=3)
Trace:	CSftpControlSocket::SendNextCommand()
Trace:	CSftpControlSocket::ConnectSend()
Command:	open "test@127.0.0.1" 22
Trace:	Looking up host "127.0.0.1"
Trace:	Connecting to 127.0.0.1 port 22
Trace:	We claim version: SSH-2.0-PuTTY_Local:_Aug_15_2015_14:41:50
Trace:	Server version: SSH-2.0-Syncplify_Me_Server
Trace:	Using SSH protocol version 2
Trace:	Doing Diffie-Hellman group exchange
Trace:	Doing Diffie-Hellman key exchange with hash SHA-1
Trace:	Host key fingerprint is:
Trace:	ssh-rsa 1024 00:d9:ec:0e:66:45:29:8d:a7:e0:42:4e:b7:71:1e:ff
Trace:	CControlSocket::DoClose(64)
Trace:	CSftpControlSocket::ResetOperation(66)
Trace:	CControlSocket::ResetOperation(66)
Error:	Could not connect to server
Trace:	CFileZillaEnginePrivate::ResetOperation(66)
Status:	Waiting to retry...
Trace:	CControlSocket::DoClose(64)
Trace:	CControlSocket::DoClose(64)
Status:	Connecting to 127.0.0.1...
Trace:	Going to execute C:\Program Files\FileZilla FTP Client\fzsftp.exe
Response:	fzSftp started, protocol_version=3
Trace:	CSftpControlSocket::ConnectParseResponse(fzSftp started, protocol_version=3)
Trace:	CSftpControlSocket::SendNextCommand()
Trace:	CSftpControlSocket::ConnectSend()
Command:	open "test@127.0.0.1" 22
Trace:	Looking up host "127.0.0.1"
Trace:	Connecting to 127.0.0.1 port 22
Trace:	We claim version: SSH-2.0-PuTTY_Local:_Aug_15_2015_14:41:50
Trace:	Server version: SSH-2.0-Syncplify_Me_Server
Trace:	Using SSH protocol version 2
Trace:	Doing Diffie-Hellman group exchange
Trace:	Doing Diffie-Hellman key exchange with hash SHA-1
Trace:	Host key fingerprint is:
Trace:	ssh-rsa 1024 00:d9:ec:0e:66:45:29:8d:a7:e0:42:4e:b7:71:1e:ff

[Drake D. Taylor]

Screenshot of the faulting module...

[Tim Kosse]

Please do the following:

• Open the registry
• Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
• Create a key with the name fzsftp.exe
• Inside this new key create a DWORD value with the name DumpType and the value 1
• Reboot

Once fzsftp.exe crashes again there should then be a minidump in the %LOCALAPPDATA%\CrashDumps directory, please attach the dump file here.

[Drake D. Taylor]

Requested MiniDump

[Tim Kosse]

The crash is due to an assertion in setting up the client-to-server keys for encryption.

Unfortunately this happens before any info about the selected ciphers can be displayed.

Please answer the following, it should help narrowing down the issue:

• Which version of Syncplify.me server are you using?
• In your server's 'SFTP Adv' settings, which "Allowed MAC algorithms" are enabled?
• At the same place, which "Allowed crypto algorithms" are enabled?

[Drake D. Taylor]

Happy to answer: I am using a beta version of Syncplify.me Server version 4.0
Here's the lists of MAC and Encryption algorithms:

    "SSHMacList" : {
        "HMAC_SHA1" : true,
        "HMAC_SHA1_96" : false,
        "HMAC_MD5" : false,
        "HMAC_MD5_96" : false,
        "NONE" : false,
        "HMAC_RIPEMD160" : true,
        "HMAC_RIPEMD" : true,
        "HMAC_RIPEMD_OPENSSH" : true,
        "HMAC_SHA256" : true,
        "HMAC_SHA256_96" : false,
        "UMAC32" : true,
        "UMAC64" : true,
        "UMAC96" : true,
        "UMAC128" : true,
        "HMAC_SHA2_256" : true,
        "HMAC_SHA2_512" : true,
        "AES128_GCM" : false,
        "AES256_GCM" : false
    },
    "SSHCryptoList" : {
        "CA_3DES" : false,
        "CA_BLOWFISH" : true,
        "CA_TWOFISH256" : true,
        "CA_TWOFISH192" : true,
        "CA_TWOFISH128" : true,
        "CA_AES256" : true,
        "CA_AES192" : true,
        "CA_AES128" : true,
        "CA_SERPENT256" : true,
        "CA_SERPENT192" : true,
        "CA_SERPENT128" : true,
        "CA_ARCFOUR" : true,
        "CA_IDEA" : true,
        "CA_CAST128" : true,
        "CA_NONE" : false,
        "CA_DES" : false,
        "CA_AES128_CTR" : true,
        "CA_AES192_CTR" : true,
        "CA_AES256_CTR" : true,
        "CA_3DES_CTR" : false,
        "CA_BLOWFISH_CTR" : true,
        "CA_TWOFISH128_CTR" : true,
        "CA_TWOFISH192_CTR" : true,
        "CA_TWOFISH256_CTR" : true,
        "CA_SERPENT128_CTR" : true,
        "CA_SERPENT192_CTR" : true,
        "CA_SERPENT256_CTR" : true,
        "CA_IDEA_CTR" : true,
        "CA_CAST128_CTR" : true,
        "CA_ARCFOUR128" : true,
        "CA_ARCFOUR256" : true,
        "CA_AES128_GCM" : false,
        "CA_AES256_GCM" : false
    }

I have set up an account for you to try and connect to that server:
​sftp://198.50.154.42:22
User: temp
Pass: temp

[Tim Kosse]

Thank you, I managed to reproduce the problem trying to connect to the test server.

[Tim Kosse]

Please disable the server's blacklist, I'm already locked out from multiple machines :(

[Drake D. Taylor]

Sorry. Done, the blacklist is not active now.

[Tim Kosse]

The cipher it tries to use is chacha20-poly1305@…

Please keep the test server configuration as-is for the time being. SFTP support in FileZilla is based on PuTTY, I may need to forward this issue to the PuTTY team for further discussion.

I should have more information tomorrow.

[Drake D. Taylor]

Please keep the test server configuration as-is for the time being

No problem. I will leave it operating that way until you give me more instructions. Thank you!

[Tim Kosse]

I managed to reproduce the issue using OpenSSH as server by adding the following two lines to /etc/sshd_config:

Ciphers=chacha20-poly1305@…
KexAlgorithms=diffie-hellman-group-exchange-sha1

You can remove the test server account, it is no longer needed.

[Drake D. Taylor]

Ok thank you!
I am deactivating the "temp" account now, but I will stay tuned to know more about the resolution of this issue. Thank you very much.

[Tim Kosse]

SSH key derivation is described in RFC 4253 section 7.2: ​https://tools.ietf.org/html/rfc4253#page-20

PuTTY assumes key derivation takes at most two iterations (yielding K1, K2).

Your server uses chacha20-poly1305@…, which has a 512 bit key with a SHA-1 hash which has 160 bits.

To obtain 512 key bits from 160 hash, ceil(512/160)=4 iterations are needed.

I'm going to submit a patch to the PuTTY mailing list soon.

[Tim Kosse]

Patch submitted upstream

[Tim Kosse]

Patch has also been applied to the FileZilla repository.

Feel tree to test the upcoming 2015-08-22 nightly: https://filezilla-project.org/nightly.php

The fix will be included in the next FileZilla release.

[Drake D. Taylor]

Interestingly enough I just downloaded the nightly build, installed it, and tried connecting to the same test server (same IP address, user and pass as above) but it still doesn't work.
It does not crash anymore, but it cannot connect to server.
I have reactivated the temporary account if you want to try yourself (maybe it's me doing something wrong).

[Tim Kosse]

You can't be using the 2015-08-22 nightly, it hasn't been built yet.

[Drake D. Taylor]

Understood that now, sorry I didn't see the date (22) in your comment. I apologize.
I will download the nightly build tomorrow.
Thank you very much for resolving this issue.

[Drake D. Taylor]

Tried the latest nightly build.
It doesn't crash anymore now... but it doesn't connect, and it returns an error regarding the size of the packet (even though all versions prior to 3.13.0 used to be able to connect to this server without issues).

Status:	Connecting to 198.50.154.42...
Trace:	Going to execute C:\Program Files\FileZilla FTP Client\fzsftp.exe
Response:	fzSftp started, protocol_version=3
Trace:	CSftpControlSocket::ConnectParseResponse(fzSftp started, protocol_version=3)
Trace:	CSftpControlSocket::SendNextCommand()
Trace:	CSftpControlSocket::ConnectSend()
Command:	open "sshbak@198.50.154.42:22" 22
Trace:	Looking up host "198.50.154.42:22"
Trace:	Connecting to 198.50.154.42 port 22
Trace:	We claim version: SSH-2.0-PuTTY_Local:_Aug_22_2015_05:38:00
Trace:	Server version: SSH-2.0-SSH
Trace:	Using SSH protocol version 2
Trace:	Doing Diffie-Hellman group exchange
Trace:	Doing Diffie-Hellman key exchange with hash SHA-1
Trace:	Host key fingerprint is:
Trace:	ssh-rsa 1024 64:ed:74:ea:05:15:96:e4:f2:78:10:39:7e:ef:b3:06
Trace:	Initialised ChaCha20 client->server encryption
Trace:	Initialised Poly1305 client->server MAC algorithm (in ETM mode) (required by cipher)
Trace:	Initialised ChaCha20 server->client encryption
Trace:	Initialised Poly1305 server->client MAC algorithm (in ETM mode) (required by cipher)
Trace:	Incoming packet length field was garbled
Error:	Incoming packet length field was garbled
Trace:	CControlSocket::DoClose(64)
Trace:	CSftpControlSocket::ResetOperation(66)
Trace:	CControlSocket::ResetOperation(66)
Error:	Could not connect to server
Trace:	CFileZillaEnginePrivate::ResetOperation(66)
Status:	Waiting to retry...
Trace:	CControlSocket::DoClose(64)
Trace:	CControlSocket::DoClose(64)

I have reactivated the temp/temp account on 198.50.154.42:22 if you want to try and see what's happening...

[Tim Kosse]

This is a bug in your server, it does not implement the selected cipher correctly.

PuTTY can talk to OpenSSH just fine when using this server, hover neither PuTTY nor OpenSSH can talk to your server with it. Considering that OpenSSH is the reference implementation for the chacha20-poly1305@… cipher, it's safe to assume that the bug is with your server.

Please contact your server vendor for assistance so that they can fix the cipher implementation.

all versions prior to 3.13.0 used to be able to connect to this server without issues

Previous versions did not support the same set of ciphers supported in 3.13.0

[Tim Kosse]

See ​http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/ssh/PROTOCOL.chacha20poly1305?content-type=text/plain for description of the cipher.

[Drake D. Taylor]

Thank you. Contacting the server vendor now.