proFTPd security bug

[seanatw]

Hi all!

The data centre we use has disabled proftpd on our servers four days ago because of this bug. I had a look around and I see no mention of it on these forums so far.

http://cve.mitre.org/cgi-bin/cvename.cgi...-2010-3867

This potentially allows root access (apparently). I was wondering if we are in fact are affected, and if so, is there a fix for this yet? I see Plesk (Parallels) have released their own fix at http://www.parallels.com/products/plesk/proftpd

Any information greatly appreciated thank you

[ephigenie]

Hello,

According to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602313
Proftpd is only vulnerable if version > 1.3.2 .
Debian stable uses 1.3.1 - please assure, that you have either a 1.3.1.x Release of proftpd or a 1.3.3c Release .

Please use the latest security updates from your distributions. SuSE, RedHat & CentOS addressed the problem with security releases as well (if matching versions).

Thank you.

[seanatw]

Hi again,

it appears to me that the information you posted is for bug http://bugs.proftpd.org/show_bug.cgi?id=3521

whereas the information I posted is for bug
http://bugs.proftpd.org/show_bug.cgi?id=3519

The confusion probably came from the plesk patch which fixes both bugs. The bug 3519 apparently effects at least 1.2.0 to 1.3.3b. We are using the debian stable version 1.3.1 as you guessed.

The list of affected versions i found is toward the bottom of this page http://web.nvd.nist.gov/view/vuln/detail...-2010-3867

If this is not applicable to us I would love to call up the data centre and tell them to reverse the changes, otherwise do I have to compile proftpd 1.3.3c?

Thanks very much for your time,
Sean.

[ephigenie]

hm might be, that there's a vulnerability in mod_site_misc.
But WE are NOT using it. Sry - thats why i didn't mentioned that one.

You can easy double check :
1) open files :

Quote:
www:~# lsof |grep proftpd|grep mod
proftpd 32119 nobody mem REG 8,1 1231955 /usr/lib/gconv/gconv-modules.cache (path inode=1230641)
proftpd 32119 nobody mem REG 8,1 28200 1245858 /usr/lib/proftpd/mod_ctrls_admin.so
proftpd 32119 nobody mem REG 8,1 84544 1245815 /usr/lib/proftpd/mod_tls.so
proftpd 32119 nobody mem REG 8,1 73088 1245931 /usr/lib/proftpd/mod_sql.so
proftpd 32119 nobody mem REG 8,1 49376 1245803 /usr/lib/proftpd/mod_ldap.so
proftpd 32119 nobody mem REG 8,1 22000 1245538 /usr/lib/proftpd/mod_sql_mysql.so
proftpd 32119 nobody mem REG 8,1 21872 607487 /usr/lib/proftpd/mod_sql_postgres.so
proftpd 32119 nobody mem REG 8,1 49744 1245912 /usr/lib/proftpd/mod_quotatab.so
proftpd 32119 nobody mem REG 8,1 8192 1245833 /usr/lib/proftpd/mod_quotatab_file.so
proftpd 32119 nobody mem REG 8,1 7072 1245800 /usr/lib/proftpd/mod_quotatab_ldap.so
proftpd 32119 nobody mem REG 8,1 15072 1245918 /usr/lib/proftpd/mod_quotatab_sql.so
proftpd 32119 nobody mem REG 8,1 46240 1245861 /usr/lib/proftpd/mod_radius.so
proftpd 32119 nobody mem REG 8,1 17408 1245930 /usr/lib/proftpd/mod_wrap.so
proftpd 32119 nobody mem REG 8,1 36160 1245857 /usr/lib/proftpd/mod_rewrite.so
proftpd 32119 nobody mem REG 8,1 12768 1245859 /usr/lib/proftpd/mod_ifsession.so
www:~#

2. the module must be mentioned in your config to be loaded.
just do a

Quote:www:/etc/proftpd# grep mod_site_misc.so modules.conf
www:/etc/proftpd#

no output is good output - if its loaded just put a # in front of the LoadModule directive & restart proftpd || kill all running proftpd processes if you're using (x)inetd.

[seanatw]

Brilliant!

This is why we use ispcp (that and because it's just plain awesome itself). We do not have any problem with our install so I can call up and confirm the guys wont turn it off again when I enable ftp.

Once again thank you for your time, very helpful

[RatS]

Thank you for reporting seanatw. We cannot monitor everything. Therefore, we appreciate any help.