After update, some users have root access through proftpd

I agree that users don't have write access. However one of the advertised advantages of ProFTPd is that they don't require chroot to keep users from going outside their home directory path.

So this is either a bug in the configuration file (which may have been written by DirectAdmin, especially if you've made no changes), or a bug in ProFTPd.

Has anyone looked for this in any ProFTPd specific forum or mailing list?

Jeff
 
Hello,

Although I've never been able to duplicate this, from the few reports I've received, the issue is random, meaning it's less likely related to the configs, as if it works sometimes, the setup would be correct. Random bugs tend to be related to memory issues with coding, or even hardware (but not likely hardware with multiple reports)

We use the option
Code: 
DefaultRoot             ~
in the <Global> section, so the chroot should be "performed immediately after a client authenticates". Since the client is able to login with his user/pass, this implies that the password entry, uid, and path should have been correctly read in.

To me, this seems like a proftpd bug, but again, with the random nature of it, it's quite difficult to report since I've got no information to provide (as I'm not able duplicate the issue)

With the release of 1.3.3c, we're no long able to use 1.3.2 for security reasons. I'm not sure if versions prior to that would be secure.. such as 1.3.1, but if anyone wishes to try that version (via versions.txt changes) to see if the issue "goes away", that is about the only option at this time for those affected by this.

We have examined pured-ftp the past. If all ftp user accounts are stored in the /etc/proftpd.passwd file, and you have no "owned" IPs with private ftp.passwd files, then pure-ftp could in theory be used. Until it supports full VirtualHost (per-IP ftp password files), it wouldn't fully work with DA.

John
 
1) Because the reports only recently started to come in.

2) The proftpd.conf has been fairly static for years.

3) The logins still work, so the correct password file is being used. The path the clients are being sent to is wrong, although correctly set in the password file.

4) The issue is only random. If it were a config issue, it would be a consistent issue, duplicated each attempt. The reports say that it will often "go away" on it's own, or a restart of proftpd fixes it. As mentioned, these types of random issues tend to be related to memory issues (eg: where an array starts walking off the end of it's allocated space).. or hardware issues, where the hardware may be overheating or failing causing memory corruption. We won't know for sure what the cause is until it can be stopped, but with the randomness of it, that makes it very difficult (ie: I have not been able to duplicate it).

5) Since the reports have been generated with source compiles of proftpd, it wouldn't be a binary issue.


The sum of all of the points tend to lean towards a bug, but again, I've seen stranger things happen before, so it doesn't mean "for sure" it's a bug. I've learned not to jump to conclusions until the conclusion is known, in which case no jumping is required.

John
 
I might have found what the bug is however don´t know it works on my server, but not tested on other´s server, like i know through ftp you can get root access however you cannot edit files. if anyone have DA installed on a empty server i would appreciate it if i have a little test account.
 
xentos said:
like i know through ftp you can get root access however you cannot edit files.
Click to expand...
That's always been true of FTP in general; ProFTPd has always disallowed that by setting a DefaultRoot as John points out in a previous post.

Jeff
 
jlasman said:
That's always been true of FTP in general; ProFTPd has always disallowed that by setting a DefaultRoot as John points out in a previous post.

Jeff
Click to expand...

Hmm, well, but with the same details you can execute which is not ftp's fault, reason why i don't want to tell it in the open is because not sure if it's 100% true, and don't want other people to abuse it because of me. told DA support to contact me via msn however never happend.
 
Hello,

You're more than welcome to send us an email, or use the Safe Submit tool to send us any relevant information, if you'd like to keep it private. We don't use msn messenger so won't be communicating that way.

John
 
Unfortunately, after all this time, this problem still has not been fixed. We did make a switch to pure-ftp (200+ servers) but pure-ftp is very unstable. We have now made a switch back to ProFTP en we are getting reports of users who manage to get into the server root (but can only edit their own files).
 
PRB said:
Unfortunately, after all this time, this problem still has not been fixed. We did make a switch to pure-ftp (200+ servers) but pure-ftp is very unstable. We have now made a switch back to ProFTP en we are getting reports of users who manage to get into the server root (but can only edit their own files).
Click to expand...

Why pure-ftpd is unstable?
 
PRB said:
Unfortunately, after all this time, this problem still has not been fixed.
Click to expand...
Have you contacted DirectAdmin Support as John has suggested to the previous poster? Have you made sure you're using the DirectAdmin configuration for ProFTPd?

What differences do you see between file/directory permissions and ownership between users who can and users who cannot see into the root filesystem? What differences do you see in their configuration settings?

Have you attempted to duplicate results of those who do, vs those who don't, get root filesystem access, by FTPing in as those users?

Jeff
 
You must log in or register to reply here.
Back
Top