/
Bugzilla – Bug 4372
SITE CPFR/CPTO do not honor <Limit> configurations
Last modified: 2019-10-12 23:48:31 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.
PR to address this issue: https://github.com/proftpd/proftpd/pull/816
PR merged to master, and backported to the 1.3.6 branch.
For future reference, this is assigned CVE-2019-12815.
(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
(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.
(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?
(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
(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!
(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?
(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
(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 ?
(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.
Resolved in 1.3.6a, 1.3.7rc1.