full-disclosure - Re: Security issue in Filezilla 3.0.9.2:passwords are stored in plain text (sitemanager.xml)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Fri, 18 Apr 2008 16:10:41 -0400
From: Valdis.Kletnieks@...edu
To: Joey Mengele <joey.mengele@...hmail.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Security issue in Filezilla 3.0.9.2:passwords
	are stored in plain text (sitemanager.xml)

On Fri, 18 Apr 2008 15:42:44 EDT, Joey Mengele said:
> I disagree, read the RFC. There are plenty of more secure FTP 
> clients such as the OpenSSH.com groups proactive secure Secure FTP 
> (sftp) implementation of FTP.

Right, except that SFTP isn't the RFC959 protocol that lives on ports 20/21,
it's an entirely different protocol layered on top of the OpenSSH on port 22.

If you actually *do* "read the RFC", RFC959, section 4.1.1 says:

         PASSWORD (PASS)

            The argument field is a Telnet string specifying the user's
            password.  This command must be immediately preceded by the
            user name command, and, for some sites, completes the user's
            identification for access control.  Since password
            information is quite sensitive, it is desirable in general
            to "mask" it or suppress typeout.  It appears that the
            server has no foolproof way to achieve this.  It is
            therefore the responsibility of the user-FTP process to hide
            the sensitive password information.

And RFC2228 (FTP Security Extensions) section 1 reminds us:

   Although the FTP control connection follows the Telnet protocol, and
   Telnet has defined an authentication and encryption option [TELNET-
   SEC], [RFC-1123] explicitly forbids the use of Telnet option
   negotiation over the control connection (other than Synch and IP).

   Also, the Telnet authentication and encryption option does not
   provide for integrity protection only (without confidentiality), and
   does not address the protection of the data channel.

Of course, the problem is that RFC2228 is *Extensions*.  Not part of the
base protocol.  And what OpenSSH's SFTP is doing is actually documented
in RFCs 4250 through 4254.

Content of type "application/pgp-signature" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/