Jump to content

Issue Information

  • #000158

  • Issue

  • 0 - None Assigned

  • Not a Bug

  • 4.0 (Build not known)

  • -

Issue Confirmations

  • Yes (0)No (0)

SmartFTP not closing SSL/TLS connection properly leaving it vulnerable to truncation attack

Posted by campbeld on 29 November 2011 - 10:57 PM

When using the Smart FTP client with explicit SSL/TLS, the connection to the FTP server is closed without regarding the SSL shutdown that is expected by servers implementing TLS.

Before closing the TCP connection, a correct TLS shutdown should be initiated.
Typical error in vsftp implmenting FTP/TLS:
[username] DEBUG: Client "IP", "Connection terminated without SSL shutdown - buggy client?"
Specification for closing TLS connections:
7.2.1. Closure alerts
Correct Behaviour for shutdown is important to ensure TLS' resistance against truncation attacks.

FileZilla apparently has this issue too: http://trac.filezill...org/ticket/7362

Relevent log entries from vsftpd:

Tue Nov 29 20:16:54 2011 [pid 3] [vrm] FTP response: Client "", "150 Here comes the directory listing."
Tue Nov 29 20:16:54 2011 [pid 2] [vrm] DEBUG: Client "", "SSL version: TLSv1/SSLv3, SSL cipher: DES-CBC3-SHA, reused, no cert"
Tue Nov 29 20:16:54 2011 [pid 2] [vrm] DEBUG: Client "", "SSL shutdown state is: NONE"
Tue Nov 29 20:16:54 2011 [pid 2] [vrm] DEBUG: Client "", "SSL shutdown state is: SSL_SENT_SHUTDOWN"
Tue Nov 29 20:16:55 2011 [pid 2] [vrm] DEBUG: Client "", "SSL shutdown state is: 3"
Tue Nov 29 20:16:55 2011 [pid 3] [vrm] FTP response: Client "", "226 Directory send OK."
Tue Nov 29 20:16:56 2011 [pid 3] [vrm] FTP command: Client "", "MDTM 2011-11-29T20:15:04+11:00-hierarchy.csv"
Tue Nov 29 20:16:56 2011 [pid 3] [vrm] FTP response: Client "", "213 20111129091503"
Tue Nov 29 20:17:20 2011 [pid 2] [vrm] DEBUG: Client "", "Connection terminated without SSL shutdown - buggy client?"

If you do the research on SSL Missing TLS shutdown means there is no easy way to detect when/if a truncation attack has been attempted.

It has been proven that an attacker can delete the final record of a SSL transmission and the alert close notify and if the client ignores the missing close notify, it is impossible for the server/client to detect whether full data transfer has occurred.

This means that a network error occuring at the right time in the file transfer can result in undetected file truncation by SmartFTP. If SmartFTP fixes this bug it will be a more reliable and safer FTPES client.

If SmartFTP does not fix this bug, it means users of FTPES should also use some sort of checksumming scheme to better verify full file transfer integrity via a method separate from FTPES. i.e. md5sum the file on the server. Transfer the data file and the md5sum and then redo the md5sum on the transferred file and compare to the original md5sum on the server.

Reference: Diana Berbecaru and Antonio Lioy "On the robustness of applications based on
the SSL and TLS security protocols"

If you review the source code of vsftpd the function "ssl_read_common", you can see where vsftpd anticipates the chance for an attacker to inject an EOF. Without a proper SSL shutdown sequence where the client receives the server close notify, it is possible for an attacker/network error to truncate the transfer in a way indistinguishable from normal operation.

Link to source in vsftpd: ftp://vsftpd.beasts.org/users/cevans/untar/vsftpd-2.3.4/ssl.c

vsftpd tries to do the right thing and log a debug warning. However, it would be much better to be able to certainly determine whether an attack or network error has occurred rather than just a normal shutdown.

changed status to: Not a Bug

0 user(s) are reading this issue

0 members, 0 guests, 0 anonymous users