ProFTPD Access Control Bug With CIDR Addresses May Let Remote Authenticated Users Access Files
|
|
SecurityTracker Alert ID: 1009997 |
|
SecurityTracker URL: http://securitytracker.com/id/1009997
|
|
CVE Reference:
CAN-2004-0432
(Links to External Site)
|
Updated: May 12 2004
|
Original Entry Date: Apr 30 2004
|
Impact:
Disclosure of user information
|
Fix Available: Yes Vendor Confirmed: Yes Exploit Included: Yes
|
Version(s): 1.2.9 to prior to 1.2.10rc1
|
Description:
A vulnerability was reported in ProFTPD. A remote authenticated user may be able to gain access to files when certain access control restrictions fail.
Jindrich Makovicka reported that access control list entries that use CIDR-based addresses (of the form 'aaa.bbb.ccc.ddd/NN') may be incorrectly processed as an 'AllowAll' directive, regardless of whether the stated directive is to allow or deny. As a result, a remote authenticated user may be able to gain access to ostensibly restricted files and directories.
The flaw reportedly resides in 'proftpd/src/dirtree.c' and was introduced into ProFTPD in version 1.2.9.
|
Impact:
A remote authenticated user may be able to gain access to access-restricted files or directories.
|
Solution:
The vendor has released a fixed version (1.2.10rc1), available at:
http://www.proftpd.org/
|
Vendor URL: bugs.proftpd.org/show_bug.cgi?id=2267 (Links to External Site)
|
Cause:
Access control error
|
Underlying OS:
Linux (Any), UNIX (Any)
|
|
Message History:
This archive entry has one or more follow-up message(s) listed below.
|
Source Message Contents
|
Date: Fri, 30 Apr 2004 13:15:57 -0400
Subject: http://bugs.proftpd.org/show_bug.cgi?id=2267
|
http://bugs.proftpd.org/show_bug.cgi?id=2267
Jindrich Makovicka reported on 2003-11-04 16:27:
Address restrictions in the form of Allow aaa.bbb.ccc.ddd/NN act like AllowAll,
because of the comparison commented out using #if 0. However, the following
"return 1" remained in the code so the comparison is left out and success is
returned. I have tried the following modification, which seems to make it work
again, at least for IPv4.
--- proftpd/src/dirtree.c 1 Nov 2003 07:11:07 -0000 1.125
+++ proftpd/src/dirtree.c 4 Nov 2003 21:18:25 -0000
@@ -1556,10 +1556,14 @@
if (cidr_mode) {
/* NOTE: encapsulation breakage note/IPv6 change needed here. */
-#if 0
- if ((cli_addr->s_addr & htonl(cidr_mask)) == cidr_addr.s_addr)
-#endif
+
+ if (pr_netaddr_get_family(cli_addr) == AF_INET) {
+ struct in_addr *cli_in_addr = pr_netaddr_get_inaddr(cli_addr);
+ if ((cli_in_addr->s_addr & htonl(cidr_mask)) == cidr_addr.s_addr) {
return 1;
+ }
+ };
+
} else {
pr_netaddr_t *acl_addr = NULL;
TJ Saunders reported on 2004-04-28 17:04:
Resolved in 1.2.10rc1.
|
|
