Proftpd 1.3.7c not working with openssl 3

[Boris Tassou]

[ Impact ]

On ubuntu 22.04, the current version of Proftpd 1.3.7c+dfsg-1build1 with the module sftp doesn't work with openssl 3.0.

[ Test Plan ]

Install proftpd with sftp module on ubuntu 22.04 and create a virtual account.

Installation details :
apt install proftpd-basic

echo "
<IfModule mod_sftp.c>
    <VirtualHost X.X.X.X>
        # Configure the server to listen on port
        Port 2222
        SFTPEngine on
        SFTPLog /var/log/proftpd/sftp.log
        TransferLog /var/log/proftpd/transfer.log
        # Configure both the RSA and DSA host keys, using the same host key
        # files that OpenSSH uses.
        SFTPHostKey /etc/proftpd/ssh_host_rsa_key
        # Auth methods
        SFTPAuthMethods password
        AuthUserFile /etc/proftpd/ftpd.passwd
        RequireValidShell off
        # SFTP specific configuration
        DefaultRoot ~
        # Some ftp options
        SFTPOptions IgnoreSFTPSetPerms IgnoreSFTPUploadPerms
        Umask 002 002
        AllowOverwrite on

    </VirtualHost>
</IfModule>" > /etc/proftpd/conf.d/sftpd.conf

echo "
# Use only AuthUserFiles when authenticating, and not the system's /etc/passwd
AuthOrder mod_auth_file.c

# Use virtual users file
AuthUserFile /etc/proftpd/ftpd.passwd" >> /etc/proftpd/proftpd.conf

Uncomment in /etc/proftpd/modules.conf :
# Install proftpd-mod-crypto to use this module for SFTP support.
LoadModule mod_sftp.c
LoadModule mod_sftp_pam.c

ftpasswd --passwd --file=/etc/proftpd/ftpd.passwd --uid=59999 --home=/home/user --shell=/bin/false --sha256 --name=sftp_test

cp /etc/ssh/ssh_host_rsa_key /etc/proftpd/ssh_host_rsa_key
cp /etc/ssh/ssh_host_rsa_key.pub /etc/proftpd/ssh_host_rsa_key.pub

systemctl restart proftpd

[ Where problems could occur ]

When you try to connect with sftp.
The result of this issue is : you can't connect with sftp.

[ Other Info ]

You can see two issues with the same problem :

https://github.com/proftpd/proftpd/issues/1448
https://github.com/proftpd/proftpd/issues/1469

The problem for sftp module is fixed in 1.3.7e version :
1.3.7e
--------------------------------
- Issue 1448 - Ensure that mod_sftp algorithms work properly with OpenSSL 3.x.

https://github.com/proftpd/proftpd/blob/1.3.7/NEWS

This is the commit for the fix :
https://github.com/proftpd/proftpd/commit/8aa39b27d8fd6ada556b51c4547a504956474078

Thanks for the help.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Florian Knauf (f-knauf)]

I found that just applying the linked patch to the deb-src package does not fix the issue. Something else that's relevant must have changed between the Ubuntu package state and that commit in the proftpd github, or one of the other Ubuntu patches interferes.

[Stefan (malfunceddie)]

Any idea when the updated version will be in the repo?

[Tam (tam)]

I'm affected by this bug as well. Please update the repo, I don't know how to apply patches.

[Tam (tam)]

Now I had to setup an extra PC with Ubuntu 20.04 just to run our proftp server.

Is there any timeframe to update the 22.04 repo? Who is doing this, can I directly contact someone to politely ask for it?

Thanks in advance.

[Andy (fre4ki)]

A timeframe would be nice.

[Tam (tam)]

It's fixed in Kinetic, see http://changelogs.ubuntu.com/changelogs/pool/universe/p/proftpd-dfsg/proftpd-dfsg_1.3.7d+dfsg-2/changelog

Any chance we can get this for Jammy?

[RICQ David (davidricq87)]

Would be great, if the fix can be apply to jammy.
This will avoid an "important" bug in a LTS which can last 10 years.

[Dan Corrigan (dangoempyrean)]

I just decided to upgrade my FTP servers from 18.04 to 22.04 and ran into this same bug.

I've been boxing with this for hours before discovering this bug.

Any workaround / fix ?

2022-10-12 22:14:49,614 mod_sftp/1.0.1[9390]: error encrypting aes128-ctr data for client: (unknown)
2022-10-12 22:14:49,614 mod_sftp/1.0.1[9390]: disconnecting 10.40.12.170 (Application disconnected)
2022-10-12 22:14:49,614 mod_sftp/1.0.1[9390]: error encrypting aes128-ctr data for client: (unknown)

[Florian Knauf (f-knauf)]

My workaround was setting up OpenSSH to listen on a second port and force sftp on that, i.e. in /etc/ssh/sshd_config

Port 22
Port 2200

...

Match LocalPort 2200
    AllowGroups ftpusers
    ChrootDirectory /srv/ftp
    ForceCommand internal-sftp
    AllowTCPForwarding no
    AllowAgentForwarding no
    X11Forwarding no

For compatibility with older clients you may have to set

HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa

And for extremely old clients possibly (but hopefully not) extend the KexAlgorithms with

KexAlgorithms +diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

Only do that as a last resort, though! OpenSSH has removed support for the old SHA1-based key exchange algorithms, which is a good thing security-wise but has tripped up some clients that worked with my previous proftpd config.

[Boris Tassou (gizmo150)]

but with this workaround, you can't have virtual users

[Tam (tam)]

Hi.

PLEASE no workarounds, we need this bug to be fixed.

[Dan Corrigan (dangoempyrean)]

I am moving away from local users, so this "workaround" doesn't work for me.
I am installing 20.04 and trying from there.

[Bruno (masterblasterlix)]

jep, same problem, please no workarounds, we need this bug to be fixed.

[l8gravely (john-stoffel)]

I see that proftpd 1.3.7e has been released which fixes this bug with openssl3 libraries. When will there be a new package released to fix this problem which breaks all kinds of working systems?

Has anyone built 1.3.7e packages yet? How hard is it?

[Tam (tam)]

Any progress?

[Bora (boraborabora)]

Hi,

Any progress here?

[Simon Chopin (schopin)]

Hi,

I don't have really have the time to do the work needed for this to move
forward, however I'm willing to mentor anyone who'd be interested. Feel
free to reach out, either by mail or on IRC :)

[Tam (tam)]

Hello Simon, did anyone contact you?

I'm an admin desperately waiting for the fix, but unfortunately not a developer.

[Simon Chopin (schopin)]

Hi,

Sadly, I don't recall anybody reaching out to me, no.

It's not really a development task, the code has already been written.
It's "just" a matter of modifying the packaging to include the patch,
and then go through the motions of filing for a Stable Release Update
(SRU) and seeing it through, see

https://wiki.ubuntu.com/StableReleaseUpdates

[Daniel (shieldwed)]

Hi,

I've been able to apply the upstream patches

- https://github.com/proftpd/proftpd/commit/8aa39b27d8fd6ada556b51c4547a504956474078
- https://github.com/proftpd/proftpd/commit/24345043de8b17fce4f88a21d13be194b8ca401b

with a removal of the NEWS and RELEASE_NOTES patch chunk on top of v1.3.7c and verify that the issue is fixed that way. Attached is a patch to the Ubuntu source package https://packages.ubuntu.com/source/jammy/proftpd-dfsg which contains the build files (proftpd-dfsg_1.3.7c+dfsg-1build1.debian.tar.xz).

So, now a https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template needs to be filled in?

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Patch to the Ubuntu source package proftpd-dfsg" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Tam (tam)]

I just checked, there's still 1.3.7c in Ubuntu 22.04. What is missing?

# apt search proftpd-basic
Sorting... Done
Full Text Search... Done
proftpd-basic/jammy 1.3.7c+dfsg-1build1 all
  Transitional dummy package for ProFTPD

[Simon Chopin (schopin)]

Honestly it's my bad, Daniel's answer fell through the cracks.

As he correctly identified, the next step would be to change the bug description to match the SRU template. Anyone can edit a bug description. Meanwhile I targeted the bug to the correct series.

Regarding the patch itself, it's customary to provide a full debdiff including the proper changelog entry. The benefits for the submitter are that they are marked as the "uploader" for the version, which is useful when applying for MOTU or Core Dev privileges.

The changelog entry must contain a reference to the bug in the form of 'LP: #1975567', and the new version number needs some care. I usually follow these guidelines for it:

https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging

The individual patch files added to debian/patches/ should follow the DEP-3 guidelines https://dep-team.pages.debian.net/deps/dep3/
A quick way to generate them is to use a full Git patch using git format-patch, and add a couple of fields. In particular here I'd like the Bug and Bug-Ubuntu fields to be added. Another way to get a Git patch from a GH repository is simply to add '.patch' at the end of a GH commit URL, for instance:

https://github.com/proftpd/proftpd/commit/8aa39b27d8fd6ada556b51c4547a504956474078.patch

When asking to sponsor a package, it's usually a good idea to include a link to a PPA where the package has been built. It shows prospective sponsors that you did due diligence, and it allows bystanders to quickly get unblocked while the SRU process move along.

I *think* that's about all the advice I have? :-)

[Tam (tam)]

Should I give up asking for the fix? Ubuntu 24-04 is near, so I just wait...

[Simon Chopin (schopin)]

As stated before: someone actually needs to do the work. This is a community-maintained package, as are all packages in the universe pocket.

I'm willing to do all the actual packaging, but I'm not in a good position to do the SRU paperwork: one needs proper reproduction steps for that, and I've never used proftpd in my life. See https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template

(anyone should be able to edit the bug description)

[Boris Tassou (gizmo150)]

Hi Simon,

Thanks for the informations, i just updated the first post with details.

But now, i don't reproduce the problem anymore....
Same configuration, same packages the only difference is some ciphers :
before :
2022-05-23 12:32:10,510 mod_sftp/1.0.1[733785]: + Session key exchange: <email address hidden>
2022-05-23 12:32:10,510 mod_sftp/1.0.1[733785]: + Session server hostkey: ssh-rsa

now :
2023-07-24 13:56:23,746 mod_sftp/1.0.1[3272]: + Session key exchange: curve25519-sha256
2023-07-24 13:56:23,746 mod_sftp/1.0.1[3272]: + Session server hostkey: rsa-sha2-512

In the changelogs, the last entry for proftpd-basic is your work :
proftpd-dfsg (1.3.7c+dfsg-1build1) jammy; urgency=medium

  * No-change rebuild against openssl3

 -- Simon Chopin <email address hidden> Fri, 03 Dec 2021 14:35:22 +0100

But it's before this issue. I continu my quest!

[Simon Chopin (schopin)]

Quoting Boris Tassou (2023-07-24 14:11:21)
> Hi Simon,
>
> Thanks for the informations, i just updated the first post with details.
>
> But now, i don't reproduce the problem anymore....
> Same configuration, same packages the only difference is some ciphers :
> before :
> 2022-05-23 12:32:10,510 mod_sftp/1.0.1[733785]: + Session key exchange: <email address hidden>
> 2022-05-23 12:32:10,510 mod_sftp/1.0.1[733785]: + Session server hostkey: ssh-rsa
>
> now :
> 2023-07-24 13:56:23,746 mod_sftp/1.0.1[3272]: + Session key exchange: curve25519-sha256
> 2023-07-24 13:56:23,746 mod_sftp/1.0.1[3272]: + Session server hostkey: rsa-sha2-512

How are you actually testing the sftpd server? Using a ssh client? It
might be that said ssh client changed its key exchange settings. For
instance, from Jammy on, openssh-client disabled SHA1 support for RSA
unless explicitly configured.

[Boris Tassou (gizmo150)]

I tried with the sftp client from ubuntu 20.04 and 22.04 and filezilla, same result, the connection is ok.

I looked the changelog of the different modules but i don't see anything who explain this difference.

[Simon Chopin (schopin)]

@gizmo150, are you using filezilla from the archive?

Can anyone else confirm or infirm the fact that the bug has disappeared?

[Boris Tassou (gizmo150)]

i'm using filezilla from the repo :

apt list --installed | grep filezilla

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

filezilla-common/lunar,lunar,now 3.63.0-1 all [installé, automatique]
filezilla/lunar,now 3.63.0-1 amd64 [installé]
libfilezilla-common/lunar,lunar,now 0.41.0-2 all [installé, automatique]
libfilezilla34/lunar,now 0.41.0-2 amd64 [installé, automatique]

[Andrei Tsukardin (cryplex)]

Can confirm that the bug has disappeared.
Tested from Debian 7-12, Centos 7, Windows Filezilla and SFTP works fine.

[Simon Chopin (schopin)]

Alright, thanks for confirming. Marking as Fix Released.