> Hello, > > 1. I know that the workaround with the DenyFilter works. Actually it turns out there is no need for DenyFilter. > 2. Proftpd by default doesn't have this filter set, neither has the > default proftpd install on slackware 8.1 In any event this is immaterial as we see later since I can't cause Proftpd 1.2.7rc3 to crash with */*/?/./whatever. > 3. The methods mentioned on the page you refer to do not work on later > proftpd versions (tested on 1.2.7rc3) because of limits set in the > code. i.e: > > ftp> ls .*./*?/.*./*?/.*./*?/.*./*?/.*./ > 200 PORT command successful > 150 Opening ASCII mode data connection for file list > 226-Out of memory during globbing of .*./*?/.*./*?/.*./*?/.*./*?/.*./ > 226 Transfer complete. > ftp> > > these proftpd versions don't even process that command. Ahh. so? The command returns an error message and the server keeps going, no additional load as far as I can tell. Your example causes no damage, at least with the 1.2.7rc3 packages at proftpd.net on a default Red Hat 8.0 box, default install, no denyfilter/etc/etc. In case you're wondering my test ftp server has 30 gigs of data nested quite deeply, so it's not like /pub/ is empty. Perhaps the slackware proftpd package is broken, or your install is, I cannot replicate this behaviour with thepackages ftom proftpd.net on Red Hat at all. What symptons are you seeing, does the server crash? Proftpd sucks up all the memory, or? > I think I have done proper research on this issue before notifying anyone. Google thinks otherwise, I remember this issue from way back when. It's been beaten to death (wuftpd. proftpd, you name it). The horse is dead. Plus the vendor would have told you about this had you contacted them first, rather then going public. You did contact the vendor first right? > People should do more research before making any conclusions, it's far > less embarassing. Yes, it is. If you can recreate this problem outside of your specific setup, especially with standard packages from proftpd.net or another vendor I'd like to know (I'm sure they would too). > Rob. Kurt Seifried, kurt@seifried.org A15B BEE5 B391 B9AD B0EF AEB0 AD63 0B4E AD56 E574 http://seifried.org/security/
