/ Bug 4372 – SITE CPFR/CPTO do not honor <Limit> configurations
Bug 4372 - SITE CPFR/CPTO do not honor <Limit> configurations
: SITE CPFR/CPTO do not honor <Limit> configurations
Status: CLOSED FIXED
Product: ProFTPD
mod_copy
: Git
: All All
: P3 normal
Assigned To: TJ Saunders
:
: Backport
:
:
  Show dependency treegraph
 
Reported: 2019-07-17 16:24 UTC by TJ Saunders
Modified: 2019-10-12 23:48 UTC (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description TJ Saunders 2019-07-17 16:24:00 UTC
A ProFTPD user reported the following via email: the mod_copy module's custom
SITE CPFR and SITE CPTO commands do not honor <Limit READ> and <Limit WRITE>
configurations as expected.

To reproduce, just enable the anonymous user example that is configured
in the Debian default proftpd.conf:

<Anonymous ~ftp>
  User                ftp
  Group                nogroup
  UserAlias            anonymous ftp
  RequireValidShell        off

  MaxClients            10
  DisplayLogin            welcome.msg
  DisplayChdir        .message

  # Limit WRITE everywhere in the anonymous chroot
  <Directory *>
    <Limit WRITE>
      DenyAll
    </Limit>
  </Directory>

</Anonymous>

ftp proftptest.domain.org (on linux, using a regular ftp client)
Login as anonymous here. You normally can't upload files, because of the
DenyAll
site cpfr welcome.msg
site cpto malicious.php

You've now created a malicious.php file with the contents of
welcome.msg. That can easily be used for RCE and similar things on many
setups.
Comment 1 TJ Saunders 2019-07-17 16:27:24 UTC
PR to address this issue:
  https://github.com/proftpd/proftpd/pull/816
Comment 2 TJ Saunders 2019-07-17 16:49:20 UTC
PR merged to master, and backported to the 1.3.6 branch.
Comment 3 TJ Saunders 2019-07-27 21:15:12 UTC
For future reference, this is assigned CVE-2019-12815.
Comment 4 Christian Wittmer 2019-07-31 16:21:20 UTC
(Mit Bezug zu comment 2)
> PR merged to master, and backported to the 1.3.6 branch.

will there be a backport for 1.3.5 branch also ?
will there be new 'security' Releases for 1.3.5 and 1.3.6 branches ?
If not, then patches would be really appreciated ... not only from my side ;-)

Thank you
Kind Regards
Christian
Comment 5 TJ Saunders 2019-07-31 19:03:35 UTC
(In reply to comment #4)
> (Mit Bezug zu comment 2)
> > PR merged to master, and backported to the 1.3.6 branch.
> 
> will there be a backport for 1.3.5 branch also ?

No.

> will there be new 'security' Releases for 1.3.5 and 1.3.6 branches ?

There will be new releases for the 1.3.6 branch, and I'll (finally!) release
1.3.7rc1.

> If not, then patches would be really appreciated ... not only from my side ;-)

The mod_copy.c changes from this commit:

 
https://github.com/proftpd/proftpd/commit/a73dbfe3b61459e7c2806d5162b12f0957990cb3

should apply to the proftpd-1.3.5/contrib/mod_copy.c source without isssue.
Comment 6 Hilmar Preuße 2019-08-01 08:26:34 UTC
(Mit Bezug zu comment 5)

> The mod_copy.c changes from this commit:
> 
> https://github.com/proftpd/proftpd/commit/a73dbfe3b61459e7c2806d5162b12f0957990cb3
> 
> should apply to the proftpd-1.3.5/contrib/mod_copy.c source without isssue.
> 
It does. However, testing the FTP server now leads to:

$ ncftp
NcFTP 3.2.5 (Feb 02, 2011) by Mike Gleason (http://www.NcFTP.com/contact/).
ncftp> open 192.168.56.102
Connecting to 192.168.56.102...
ProFTPD 1.3.5b Server (Debian) [::ffff:192.168.56.102]
<snip>
Anonymous access granted, restrictions apply
Logged in to 192.168.56.102.
ncftp / > site cpfr welcome.msg
File or directory exists, ready for destination name
ncftp / > site cpto malicious.php
Remote host has closed the connection.
ncftp>

So the server is not vulnerable to CVE-2019-12815, but the behavior is quite
unexpected, right?
Comment 7 Paul Howarth 2019-08-01 08:44:39 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > (Mit Bezug zu comment 2)
> > > PR merged to master, and backported to the 1.3.6 branch.
> > 
> > will there be a backport for 1.3.5 branch also ?
> 
> No.
> 
> > will there be new 'security' Releases for 1.3.5 and 1.3.6 branches ?
> 
> There will be new releases for the 1.3.6 branch, and I'll (finally!) release
> 1.3.7rc1.
> 
> > If not, then patches would be really appreciated ... not only from my side ;-)
> 
> The mod_copy.c changes from this commit:
> 
>  
> https://github.com/proftpd/proftpd/commit/a73dbfe3b61459e7c2806d5162b12f0957990cb3
> 
> should apply to the proftpd-1.3.5/contrib/mod_copy.c source without isssue.

Not really. It includes use of pr_cmd_set_errno(), which was introduced in
1.3.6. The PROFTPD_VERSION_NUMBER check in mod_copy (and probably several other
modules) should probably be adjusted to reflect this.

I applied this patch against 1.3.5e for EPEL-7:
https://src.fedoraproject.org/rpms/proftpd/blob/f755408724fe4a5b299c70543e9efe780fefff2b/f/proftpd-1.3.5e-CVE-2019-12815.patch
Comment 8 Hilmar Preuße 2019-08-01 10:29:07 UTC
(Mit Bezug zu comment 7)

> Not really. It includes use of pr_cmd_set_errno(), which was introduced in
> 1.3.6. The PROFTPD_VERSION_NUMBER check in mod_copy (and probably several other
> modules) should probably be adjusted to reflect this.
> 
> I applied this patch against 1.3.5e for EPEL-7:
> https://src.fedoraproject.org/rpms/proftpd/blob/f755408724fe4a5b299c70543e9efe780fefff2b/f/proftpd-1.3.5e-CVE-2019-12815.patch

Applies to proftp 1.3.5b (Debian stretch) too. Thanks for the patch!
Comment 9 Hilmar Preuße 2019-08-01 10:29:42 UTC
(Mit Bezug zu comment 7)

> Not really. It includes use of pr_cmd_set_errno(), which was introduced in
> 1.3.6. The PROFTPD_VERSION_NUMBER check in mod_copy (and probably several other
> modules) should probably be adjusted to reflect this.
> 
> I applied this patch against 1.3.5e for EPEL-7:
> https://src.fedoraproject.org/rpms/proftpd/blob/f755408724fe4a5b299c70543e9efe780fefff2b/f/proftpd-1.3.5e-CVE-2019-12815.patch

Applies to proftp 1.3.5b (Debian stretch) too. Thanks for the patch!
Comment 10 Paul Howarth 2019-08-01 11:44:41 UTC
(In reply to comment #9)
> (Mit Bezug zu comment 7)
> 
> > Not really. It includes use of pr_cmd_set_errno(), which was introduced in
> > 1.3.6. The PROFTPD_VERSION_NUMBER check in mod_copy (and probably several other
> > modules) should probably be adjusted to reflect this.
> > 
> > I applied this patch against 1.3.5e for EPEL-7:
> > https://src.fedoraproject.org/rpms/proftpd/blob/f755408724fe4a5b299c70543e9efe780fefff2b/f/proftpd-1.3.5e-CVE-2019-12815.patch
> 
> Applies to proftp 1.3.5b (Debian stretch) too. Thanks for the patch!

Did it work any better when you tested it though?
Comment 11 Hilmar Preuße 2019-08-01 11:50:27 UTC
(Mit Bezug zu comment 10)
> (In reply to comment #9)
> > (Mit Bezug zu comment 7)

> > > https://src.fedoraproject.org/rpms/proftpd/blob/f755408724fe4a5b299c70543e9efe780fefff2b/f/proftpd-1.3.5e-CVE-2019-12815.patch
> > 
> > Applies to proftp 1.3.5b (Debian stretch) too. Thanks for the patch!
> 
> Did it work any better when you tested it though?
> 
Without the patch I the "site cpto malicious.php" command is accepted, w/ the
patch it is denied as expected. So I'd conclude the patch solves the problem
for the 1.3.5 line

Hilmar
Comment 12 Christian Wittmer 2019-08-02 14:51:25 UTC
(Mit Bezug zu comment 7)

> > https://github.com/proftpd/proftpd/commit/a73dbfe3b61459e7c2806d5162b12f0957990cb3
> > 
> > should apply to the proftpd-1.3.5/contrib/mod_copy.c source without isssue.
> 
> I applied this patch against 1.3.5e for EPEL-7:
> https://src.fedoraproject.org/rpms/proftpd/blob/f755408724fe4a5b299c70543e9efe780fefff2b/f/proftpd-1.3.5e-CVE-2019-12815.patch

reviewed your patch and wondering why your patch is different from original one
and two lines are missing.

Two times the 'pr_cmd_set_errno(cmd, xerrno);' is missing. Why ?
Comment 13 Paul Howarth 2019-08-03 08:58:56 UTC
(In reply to comment #12)
> (Mit Bezug zu comment 7)
> 
> > > https://github.com/proftpd/proftpd/commit/a73dbfe3b61459e7c2806d5162b12f0957990cb3
> > > 
> > > should apply to the proftpd-1.3.5/contrib/mod_copy.c source without isssue.
> > 
> > I applied this patch against 1.3.5e for EPEL-7:
> > https://src.fedoraproject.org/rpms/proftpd/blob/f755408724fe4a5b299c70543e9efe780fefff2b/f/proftpd-1.3.5e-CVE-2019-12815.patch
> 
> reviewed your patch and wondering why your patch is different from original one
> and two lines are missing.
> 
> Two times the 'pr_cmd_set_errno(cmd, xerrno);' is missing. Why ?

As I mentioned in Comment #7, the pr_cmd_set_errno() function was introduced in
proftpd 1.3.6 and therefore cannot be used in proftpd 1.3.5. Hence the error
handling code in my patch is adjusted to be in the style used elsewhere in
proftpd 1.3.5, without using that function.
Comment 14 TJ Saunders 2019-10-12 23:48:31 UTC
Resolved in 1.3.6a, 1.3.7rc1.