proftpd 1.3.2c with SSL is useless in Ubuntu 10.04

[Claes Löfqvist]

Binary package hint: proftpd-basic

Hi,

Due to a bug in proftpd v1.3.2c clients fail to connect to the server since the server is abruptly disconnecting when a renegotiation is initiated by the client. The disconnecting is however a "freshly" added security feature so that part should be considered normal.
The problem occur when you try to disable this function (which has to be done since (at least) the commonly used FileZilla Client is not able to handle this yet). The TLSOptions AllowClientRenegotiations doesn't work and that, I read somewhere, is due to something regarding to the openssl version presently used in Ubuntu 10.04.

(I made an attempt to move my up and running FTP server from Ubuntu 9.10 to 10.04. This issue has however made me regroup to 9.10 again.)

I'm adding as much info as I can. I believe that this issue is fixed in the later versions of proftpd. The version 1.3.2e released 24 Feb 2010 would probably be the wise choice!

Best regards Claes Löfqvist

OUTPUT FROM: lsb_release -rd
============================
Description: Ubuntu 10.04 LTS
Release: 10.04

OUTPUT FROM: uname -a
=====================
Linux myserver 2.6.32-22-generic-pae #33-Ubuntu SMP Wed Apr 28 14:57:29 UTC 2010 i686 GNU/Linux

OUTPUT FROM: apt-cache policy proftpd-basic
==================================
proftpd-basic:
  Installed: 1.3.2c-1
  Candidate: 1.3.2c-1
  Version table:
 *** 1.3.2c-1 0
        500 http://se.archive.ubuntu.com/ubuntu/ lucid/universe Packages
        100 /var/lib/dpkg/status

OUTPUT FROM: apt-cache policy openssl
==================================
openssl:
  Installed: 0.9.8k-7ubuntu8
  Candidate: 0.9.8k-7ubuntu8
  Version table:
 *** 0.9.8k-7ubuntu8 0
        500 http://se.archive.ubuntu.com/ubuntu/ lucid/main Packages
        100 /var/lib/dpkg/status

TAIL OF: /var/log/proftpd/proftpd.log
=====================================
May 14 12:15:43 myserver proftpd[3826] myserver.example.com (192.168.0.2[192.168.0.2]): FTP session opened.
May 14 12:15:43 myserver proftpd[3826] myserver.example.com (192.168.0.2[192.168.0.2]): USER AUser: Login successful.
May 14 12:15:43 myserver proftpd[3826] myserver.example.com (192.168.0.2[192.168.0.2]): mod_tls/2.2.2: client-initiated session renegotiation detected, aborting connection
May 14 12:15:43 myserver proftpd[3826] myserver.example.com (192.168.0.2[192.168.0.2]): FTP session closed.

TAIL OF: /var/log/proftpd/tls.log
=================================
May 14 12:15:43 mod_tls/2.2.2[3826]: using default OpenSSL verification locations (see $SSL_CERT_DIR environment variable)
May 14 12:15:43 mod_tls/2.2.2[3826]: TLS/TLS-C requested, starting TLS handshake
May 14 12:15:43 mod_tls/2.2.2[3826]: TLSv1/SSLv3 connection accepted, using cipher DHE-RSA-AES128-SHA (128 bits)
May 14 12:15:43 mod_tls/2.2.2[3826]: Protection set to Private
May 14 12:15:43 mod_tls/2.2.2[3826]: starting TLS negotiation on data connection
May 14 12:15:43 mod_tls/2.2.2[3826]: warning: client-initiated session renegotiation detected, aborting connection

EXCERPT FROM: /etc/proftpd/tls.conf
===================================
#
# Per default drop connection if client tries to start a renegotiate
# This is a fix for CVE-2009-3555 but could break some clients.
#
TLSOptions AllowClientRenegotiations

LOG FROM: FileZilla Client (v3.3.2.1)
====================================
Status: Connecting to 192.168.0.202:21...
Status: Connection established, waiting for welcome message...
Response: 220 ProFTPD 1.3.2c Server ready.
Command: AUTH TLS
Response: 234 AUTH TLS successful
Status: Initializing TLS...
Status: Verifying certificate...
Command: USER AUser
Status: TLS/SSL connection established.
Response: 331 Password required for AUser
Command: PASS **************
Response: 230 User AUser logged in
Command: SYST
Response: 215 UNIX Type: L8
Command: FEAT
Response: 211-Features:
Response: MDTM
Response: MFMT
Response: AUTH TLS
Response: UTF8
Response: MFF modify;UNIX.group;UNIX.mode;
Response: MLST modify*;perm*;size*;type*;unique*;UNIX.group*;UNIX.mode*;UNIX.owner*;
Response: PBSZ
Response: PROT
Response: REST STREAM
Response: LANG en-US.UTF-8*
Response: SIZE
Response: 211 End
Command: OPTS UTF8 ON
Response: 200 UTF8 set to on
Command: PBSZ 0
Response: 200 PBSZ 0 successful
Command: PROT P
Response: 200 Protection set to Private
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is the current directory
Command: TYPE I
Response: 200 Type set to I
Command: PASV
Response: 227 Entering Passive Mode (192,168,0,202,194,196).
Command: MLSD
Error: GnuTLS error -9: A TLS packet with unexpected length was received.
Status: Server did not properly shut down TLS connection
Response: 150 Opening ASCII mode data connection for MLSD
Error: Connection closed by server

LINKS
=====
Someone seems to have reported a similar issue to our Debian friends:
http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/77251f6bd43af40a

[Laryllan (laryllan)]

I found a link to a Debian bug that might help:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558597#30

[Claes Löfqvist (slarti)]

Ahh, there it is... I knew I had read it before, but couldn't find it when I was to report this problem. Thanks Laryllan!
Lots of information there... possible solutions seems to be: upgrading proftpd, upgrading openssl or even downgrading proftpd.

I have now temporarily sidestepped this problem by downgrading proftpd. The following parameters was considered in this decision:
1. I don't want to build stuff and inject manually in my system (too much job to maintain securely in the long run).
2. I couldn't find an upgraded Ubuntu package of openssl (this would otherwise also solved the problem. See Laryllan's link)
3. Reverting to Ubuntu 9.10 seemed like... overreacting!
4. It's a plus if an "apt-get upgrade" can be used to correct "the fix" later on.

If someone is interested in exactly how I downgraded... here comes details:

-----------------------------------------------------------
STEP 1: I downloaded an older package of proftpd from the previous Ununtu release:
  http://packages.ubuntu.com/karmic/proftpd-basic
  (in my case: proftpd-basic_1.3.2-3_i386.deb)

STEP 2: I then removed the proftpd installed in my system:
  sudo apt-get remove proftpd

STEP 3: Thereafter did I install the downloaded version:
  sudo dpkg --install proftpd-basic_1.3.2-3_i386.deb

STEP 4: Next I commented the "TLSOption AllowClientRenegotiations" line in the tls.conf file:
  sudo vim /etc/proftpd/tls.conf

STEP 4b: The line now looking like this:
#TLSOptions AllowClientRenegotiations

STEP 5: Starting the downgraded ftp server:
  sudo /etc/init.d/proftpd start

FINAL STEP: I successfully connected to my downgraded ftp server with a Filezilla Client.
-----------------------------------------------------------

Running "apt-get upgrade" now will of course upgrade and ruin what we just accomplished. But I guess if I have to upgrade the system I just have to redo the STEPS 1, 2, 3 and 5 from above and I'm back "off" track again.

OUTPUT FROM: sudo apt-get remove proftpd
========================================
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting proftpd-basic instead of proftpd
The following packages were automatically installed and are no longer required:
  openbsd-inetd
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
  proftpd-basic
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 2,187kB disk space will be freed.
Do you want to continue [Y/n]?
(Reading database ... 56550 files and directories currently installed.)
Removing proftpd-basic ...
 * Stopping ftp server proftpd [ OK ]
Processing triggers for man-db ...
Processing triggers for ureadahead ...

OUTPUT FROM FIRST ATTEMPT: sudo /etc/init.d/proftpd start
=========================================================
 * Starting ftp server proftpd
 - mod_tls/2.2.1: compiled using OpenSSL version 'OpenSSL 0.9.8g 19 Oct 2007' headers, but linked to OpenSSL version 'OpenSSL 0.9.8k 25 Mar 2009' library
 - Fatal: TLSOptions: : unknown TLSOption 'AllowClientRenegotiations' on line 39 of '/etc/proftpd/tls.conf'
   [fail]

OUTPUT FROM SECOND ATTE...

[Christopher K. (christopher-christosoft)]

I had the same issue and "fixed" it like Claes Löfqvist explained. Worked perfectly, thanks.
Additional hint: You can tell apt-get not to update this package ("pin" it) by creating a file in /etc/apt/preferences.d (e.g. /etc/apt/preferences.d/proftpd) with the following content:
Package: proftpd-basic
Pin: version 1.3.2-3
Pin-Priority: 999

Note that you might need to adjust the Pin-Version to the one you downgraded to. Synaptic (if you use it) offers similar options via GUI (which only affect synaptic, not apt-get).

I'd also like to add the Release Notes of Proftpd 1.3.2d which clearly relate to this issue:

1.3.2d (maintenance)
---------------------

  + Fixed mod_tls compilation when using OpenSSL versions older than 0.9.7.
  + Fixed SSL/TLS (broken due to bad backport)
  + Fixed RADIUS authentication on 64-bit platforms.

I used OpenSSL newer than the version mentioned so I think the second issue is what our problem really is.

I think that the current version of proftpd (1.3.2e) should appear in the repository fast to fix this issue.

[Claes Löfqvist (slarti)]

Ooh yeah, Christopher's hint nailed it! Now I can keep my system updated again without having to repeat the proftpd downgrade procedure afterwards. Thanks!

I guess now we just have to wait for this issue to be fixed by some warm hearted person. The 1.3.2e fix seems actually to have been released by the proftpd team back in FEBRUARY so I don't think anyone could say that it would be overly hasty to include it now?

A NOTE to all of us downgraders (put a yellow sticker up right now)...
  WHEN THIS ISSUE HAS BEEN SOLVED:
  DON'T FORGET TO DELETE THE DOWNGRADE PIN ( sudo rm /etc/apt/preferences.d/proftpd ) !
  otherwise the proftpd server will remain downgraded forever, which of course can get this saga (yes, I'm swedish ;) to end up in security holes!

Best regards Claes Löfqvist.

[KiJune Yoon (kijune)]

Thanks,Claes and Christopher.
I had exactly the same problem. and now I wait for new version to be in the repository.

[Christophe Van Reusel (christophevr)]

Hallo,

I solved This problem By compiling self the latest stable release proftpd 1.3.3.3a , yes I did need to tweak it al a bit and spend a lot of time . But now it Runs perfect.

Just the ubuntu's openssl the standard from 10.04 .
A little hint Before you uninstall the proftpd version from ubuntu, Copy and safegard first the
Ubuntu's /etc/proftpd/proftpd.conf file
Ubuntu's /etc/init.d/proftpd start/stop file
Ubuntu's /etc/default/proftpd file

So it wil be easy later on to reinstall the automated start stop deamons from ubuntu.
Before you configure read of course the compiling manual and select all modules and options you will need.
Also take a close look at the install locations and eventually change them.
I just changed the location of /var/run section and proftpd's config file to match that from ubuntu. Then I later on patched the proftpd start/stop file from ubuntu To match the new start up location off the proftpd binary to /usr/local/sbin bin . So the day that ubuntu's included package proftpd is upgraded I easely will find the self compiled files and can remove them.

Now the open ssl options are a bit different.

TLSOptions AllowClientRenegotiations is not needed anymore
But you will need to ad another one ,
This is
 TLSOptions NoSessionReuseRequired

At least for filezilla it need to be set.

gr christophe

[Christopher K. (christopher-christosoft)]

Thanks Cristophe for your feedback. This proves that the new version fixes this bug.
I just can't understand why such an important feature like SSL is kept unusable in the stable ubuntu package of proftpd. I really get the impression, that support of the proftpd-package in Ubuntu is not very good as I am struggling with another (even older) bug in the latest proftpd-package for Hardy which has also not been solved for ages now ans even is considered a security risk.

Maybe vsftpd is an alternative as its in the main repository and not in universe like proftpd, so updates might come more frequently. I think I might have a try with vsftpd.

[Christophe Van Reusel (christophevr)]

Hallo Christopher,

Yes seems that vsftpd is runnig fine as well. However the old bug may as well be in open ssl self. Those day's I may sound a little paranio but watch out security wise. Cause older stuf maybe vulnerable . There are now a lot of hackers (say eighter evoluated lamers) with very bad intenses, for viruses it's ok on linux for the moment don't worry about them and the way how file system work's in linux and mac make it quit impossible to install those but trough mail or server you can become and unwilling distributor of them. But for spyware and some bots even linux and mac are vulnerable if you don't have a good firewall . The best is always a good NAT router With Good configurable firewall.
With proftpd its easy to configure main server for my dmz zone on port 21 That one is not accesible trough my router but in the same time blocked by my provider as well. But perfect for my own internal network (the fastes and most reliable server I find for an network in an multi operating systems enviroment) . Then I configure just a virtual server host user limited On an port above 1024 with acouple of passive ports using the masqueradeadres as this one is ssl required I need that to open the passive data ports on my router while giving it the correct translated ip (trough Nat) on the client. Of course That virtual server i chrooted to a certain directory as well.

I don't now if vsftpd can do that.

gr christophe

[Christopher K. (christopher-christosoft)]

Thanks chrstophe for the reply. As hardy is LTS and should be supported until April 2011, I thought security patches should be included in the recent packages. And I can't dist-upgrade this server as it's a vServer.
My home server is running lucid, though (and therefore affected with this bug).

Today I saw that maverick (upcoming Ubuntu 10.10) has an updated proftpd-version in its repository:
http://packages.ubuntu.com/maverick/proftpd-basic
It's 1.3.2e-4 which was released 24/Feb/2010 by proftpd-project, but seems to be a stable version which does not have the bug we encounter (from the version number and changelog - I did not try it myself yet).
I think 1.3.2e is more something for 10.04 and 10.10 should include 1.3.3a (which was released 01/Jul/2010 by the proftpd-project and seems to be a stable and reliable version as well). But I think they just synced with Debian unstable and got 1.3.2e from there, so we should be happy with that. I just had a look into the Debian repository: They now have 1.3.3a in unstable but it was marked experimental until 05 Jul 2010, so probably the sync for maverick ended before that date so 1.3.2e is what we'll get for maverick.
As lucid is LTS I think 1.3.2-e will come to the lucid repository some day, but I think I'll update my lucid machine to maverick as soon as it seems reliable (December maybe).

Probably the maverick-package installs in lucid as well, but I think this would be a messy solution as well.

Can somebody please confirm (try by himself) if this bug is really fixed in maverick?

[Christopher K. (christopher-christosoft)]

I just had to try it:

I installed maverick in VirtualBox. I used Ubuntu 10.10 Alpha 3 (the beta-download-link wouldn't work), Desktop edition (maverick-desktop-i386). After Installation I updated everything using apt (Synaptic crashed but worked after it had been updated using apt), which nearly replaced the whole system and took as long as installation.
I then installed the proftpd-basic package (version 1.3.2e-4) and configured it as a standalone server with SSL encryption configured (everything using pretty default settings, no TLSOptions set at all).
I then connected using FileZilla 3.3.4.1 from the Windows 7 Host machine into the Maverick Virtual machine using "FTPES" (explicit SSL).

It worked perfectly, just out of the box! No special configuration.

So I can definitely say: This bug is fixed in Maverick. Now I'm looking for to its final release.

[Christophe Van Reusel (christophevr)]

Hello,

Thank's for this info. So the day maverick is out on stable I'll be able to use this as well.

One remark, If they change the proftpd version from maverick to 1.3.3.3a , which still is quit possible.

Think about the new TLSOptions which had to be added and is

TLSOptions NoSessionReuseRequired

At least this is needed when I use filezilla as client from other linux pc's. (explicit SSL)
on version 1.3.3.3a

gr and looking out for stable maverick christophe

[Neil Wilson (neil-aldur)]

Anybody had any luck with the standard Lucid package using.

TLSOptions AllowClientRenegotiations
TLSRenegotiate none

Seems to work here.

[Claes Löfqvist (slarti)]

Hi and sorry for not changing the status of this bug earlier... I didn't know I could/should do it! :-/

This issue has been solved in Ubuntu 10.10 as far as I can see. Ubuntu 10.10 is using ProFTPD version 1.3.2e and it works perfectly!
Thanks for all the input and help that has been given by so many. This is a good and healty community for sure!

Happy New Year! /Claes

[Marcus Walther (c-launchpad-marcus-walther-de)]

Is there any date known when the fix/update also will find it's way into lucid?

[jonaz__ (jonaz-86)]

When will this be fixed in Ubuntu 10.04.2 LTS?

Im running LTS om my server and i really DONT like not beeing able to run proftpd... :(

[Francesco Paolo Lovergine (frankie)]

On Fri, Apr 29, 2011 at 08:32:34AM -0000, jonaz__ wrote:
> When will this be fixed in Ubuntu 10.04.2 LTS?
>
> Im running LTS om my server and i really DONT like not beeing able to
> run proftpd... :(
>

In Debian never distributed 1.3.2 series, this is the risk of distributing snapshots
in a whatever time point during the development cycle.
I would suggest you to 'dget' the latest proftpd sourceversion in squeeze pool
and build it on your ubuntu. If you also follow security.debian.org, you
will get an acceptable result, at least not worse than currenty in stable.

--
Francesco P. Lovergine

[Francesco Paolo Lovergine (frankie)]

On Fri, Apr 29, 2011 at 11:13:26AM +0200, Francesco P. Lovergine wrote:
> On Fri, Apr 29, 2011 at 08:32:34AM -0000, jonaz__ wrote:
> > When will this be fixed in Ubuntu 10.04.2 LTS?
> >
> > Im running LTS om my server and i really DONT like not beeing able to
> > run proftpd... :(
> >
>
> In Debian never distributed 1.3.2 series, this is the risk of distributing snapshots
> in a whatever time point during the development cycle.
> I would suggest you to 'dget' the latest proftpd sourceversion in squeeze pool
> and build it on your ubuntu. If you also follow security.debian.org, you
> will get an acceptable result, at least not worse than currenty in stable.
>

To say better, we are currently working on 1.3.4rc2 with the final goal
of distributing 1.3.4 in wheezy. If people will distribute instead
a RC2 snapshot in Ubuntu (as done in the past), they are looking for
a good pile of problems that upstream and us will ignore.

--
Francesco P. Lovergine

[ralphie (ralphie)]

I'm running Ubuntu Lucid Lynx and this configuration works (tested with FileZilla client 3.3.1):

1. Install proftpd-basic 1.3.2c-1ubuntu0.1

2. Install gadmin-proftpd 1:0.3.8-1

3. Launch gadmin-proftpd and configure your settings. Under Secure communications: Verify clients: must be set to "Off". (FileZilla client does not support client certificates as a security feature since that is handled by a Username & Password) Apply your settings.

4. Modify /etc/proftpd/proftpd.conf. Paste this line: TLSOptions AllowClientRenegotiations above the line that says: TLSRenegotiate required off (Save your changes)

5. Restart gadmin-proftpd and activate the server

Now here are the last two very important details for everything to work perfectly.

1. If the server ever fails to start you must make sure /var/run/proftpd exists. For some strange reason it disappears on shutdown (I have no idea why, Security feature?) Simple fix: run this line in a terminal: sudo mkdir /var/run/proftpd

2.When connecting with FileZIlla client you must use ftpes:// before the hostname (the "e" stands for explicit and yes it is still a secure connection)

Note: You may not be able to connect to yourself using your own local ip address. So try connecting using:

a. Your dynamic domain name or

b. Another computer on your network or

c. A remote computer