ProFTPd update?

[ActiveDomain.NL]

Is there a Source RPM or a fixed RPM available for the ProFTPd used by DirectAdmin (I'm using RH 8)?

This because of the ProFTPd security bug: www.proftpd.net

[l0rdphi1]

I looked and cannot locate a patched RPM. I'm waiting for John to reply with the ./configure string for ftp://ftp.proftpd.org/distrib/source/proftpd-1.2.8p.tar.gz

[l0rdphi1]

The following appears to work. Use at your own risk.

wget ftp://ftp.proftpd.org/distrib/source/proftpd-1.2.8p.tar.gz

gzip -d pro*
tar xvf pro*
cd pro*

cp /etc/proftpd.conf /etc/proftpd.backup.conf

./configure --sysconfdir=/etc --localstatedir=/usr/sbin
make
make install

service proftpd restart

[ActiveDomain.NL]

Seems to work fine here.

Thanks!

[ActiveDomain.NL]

I don't see why DA should take responsibility for security flaws in third party software. Of course it would be nice if they send a message to everyone with instructions how to patch the software, but in my opinion it's the task of a system administration to keep everything uptodate.

[l0rdphi1]

It is possible for DA to update itself.

[ActiveDomain.NL]

True, but I don't think third party software (like ProFTPd and MySQL) is something that should be updated automatically. What if you make some customisations or use your own build?

[ProWebUK]

Originally posted by iStormy
If DirectAdmin installed it on my system, I expect them to be responsible for it. It's part of their system. Their program downloaded it to my server, their program configured it, their program compiled it, their program launched it.

But I'm new to DA, and I don't yet know their way of doing things. I just know that CPanel had a new version of ProFTPd ready for automatic update 2 hours & 44 minutes after the first post appeared in their forums.

Now, I know the evil of CPanel, which is why I'm here, and not there. :D But if DA installs 3rd party software and then has nothing further to do with it, this should be clearly stated somewhere so that us new clients will be fully aware of our responsibilities.

Plesk, Ensim Pro, Ensim Basic, cPanel and DirectAdmin all get the software, all configure the software and all compile it.

cPanel having an automated update feature has its good side but also its bad, the good - its easier for a newbie to update without much if any experience and regular updates are better known as its in the control panel, the bad - a lot of software should not be updated automatically, it can easily break things and you do not have any idea what it is doing.

I personally prefer updating software myself for a few reasons.

1 - i know whats happening when i run updates.
2 - i know all the files being modified.
3 if there is a problem with software its usually much easier to revert when done manually than an automatic installation.
4 - when manually updating software you can usually change the configuration unlike most automatic updates...

IMHO if you dont know how to manually update software you should be looking at going through either the managed server route or look for a server administrator to do the work for you, unless of course, you have lots of time to spend learning :)

Chris

[DirectAdmin Support]

By the way, the new proftpd is available in rpm form:

7.2 http://files.directadmin.com/services/7.2/proftpd-1.2.8p-1.i386.rpm
7.3 http://files.directadmin.com/services/7.3/proftpd-1.2.8p-1.i386.rpm
8.0 http://files.directadmin.com/services/8.0/proftpd-1.2.8p-1.i386.rpm
9.0 http://files.directadmin.com/services/9.0/proftpd-1.2.8p-1.i386.rpm

[edit]

John

[ProWebUK]

if any users dont notice, the links john posted are in the following order:

RedHat 7.2
RedHat 7.3
RedHat 8
RedHat 9

Just to stop confusion :D

Chris

[Icheb]

*kick*

I just received a bugtraq (the securityfocus list) list mail about a new exploit in ProFTPD:


Mandrakelinux Security Update Advisory
Package name: proftpd
Advisory ID: MDKSA-2004:041
Date: April 30th, 2004

Affected versions: 10.0

Problem Description:

A portability workaround that was applied in version 1.2.9 of the
ProFTPD FTP server caused CIDR based ACL entries in "Allow" and "Deny"
directives to act like an "AllowAll" directive. This granted FTP
clients access to files and directories that the server configuration
may have been explicitly denying.

This problem only exists in version 1.2.9 and has been fixed upstream.
A patch has been applied to correct the problem.

References:

http://bugs.proftpd.org/show_bug.cgi?id=2267

In the references i found that it got broken in 1.2.9 and fixed in:
------- Additional Comment #15 From TJ Saunders 2004-04-28 17:04 -------
Resolved in 1.2.10rc1.


So perhaps updating isn't a very bad idea :D

[DirectAdmin Support]

I'll add it to my list of things to do :) Note that we don't use Allow/Deny anywhere really, so for most people it shouldn't be a huge issue, but updating won't hurt in any case.

John

[@how@]

Originally posted by l0rdphi1
The following appears to work. Use at your own risk.

wget ftp://ftp.proftpd.org/distrib/source/proftpd-1.2.8p.tar.gz

gzip -d pro*
tar xvf pro*
cd pro*

cp /etc/proftpd.conf /etc/proftpd.backup.conf

./configure --sysconfdir=/etc --localstatedir=/usr/sbin
make
make install

service proftpd restart


i do wget ftp://ftp.proftpd.org/distrib/source/proftpd-1.2.10.tar.gz
and all :) you say
done 100%
and still ProFTPd 1.2.9 not ProFTPd 1.2.10 :confused:

[@how@]

i scan and i found
- ProFTPd 1.2.9 [ Old or patched version ]
- ProFTPd 1.2.10 [ OK ]
:confused:
2 ProFTPd runing

[jmstacey]

I bet you didn't uninstall the old version before installing the new version (remember to keep any configuration files ;) )

[DamnSkippy]

Originally posted by DirectAdmin Support
By the way, the new proftpd is available in rpm form:

7.2 http://files.directadmin.com/services/7.2/proftpd-1.2.8p-1.i386.rpm
7.3 http://files.directadmin.com/services/7.3/proftpd-1.2.8p-1.i386.rpm
8.0 http://files.directadmin.com/services/8.0/proftpd-1.2.8p-1.i386.rpm
9.0 http://files.directadmin.com/services/9.0/proftpd-1.2.8p-1.i386.rpm

[edit]

John

Does this not effect the FreeBSD installs? This seems like a post that should have it's own forum topic and only DA employees/forum mods can post in it. That way we all know when and where the latest official updates are made available.

I am a hands on admin and I do not mind patching myself but their is a very valid point about if it is part of the software bundle that DA installs then they need to roll the patches for it. I do not seem them as responsible for the third party software but if they install it as part of their system they should keep the system up to date.

Just my .02 worth :)

[jmstacey]

Customapache handles most of it, but I don't remember seeing any documentation or agreement that DirectAdmin would keep the system uptodate for us after installation.
They do make new packages as seen necassary which you can download...

[@how@]

Originally posted by jmstacey
I bet you didn't uninstall the old version before installing the new version (remember to keep any configuration files ;) )


:( how to uninstall old one now :confused:

[jmstacey]

Uninstall the package if that was how it was originally installed......

[BigWil]

Ok lets bump this bad boy!

ProFTPD.org now shows a fix to the "Timing attack" as described on their website in further detail. The attack apparently was detected awhile ago but no fix was presented until November 10th. Yah that was months ago but what can I say.

http://www.proftpd.org
http://www.castaglia.org/proftpd/modules/mod_delay.html
http://security.lss.hr/index.php?page=details&ID=LSS-2004-10-02

The mod_delay is one fix but it doesn't seem to be available in the release of 1.2.10 coming down from DA. I need to be able to use these directives to secure this vulnerability.

DelayEngine off
DelayTable /var/log/proftpd/proftpd.delay

The 1.2.10 received from DA states it was a build from Oct 1st. So I am thinking there may be a more recent build.

- ProFTPD Version: 1.2.10 (stable)
- Scoreboard Version: 01040002
- Built: Fri Oct 1 11:53:42 MDT 2004
- Module: mod_core.c
- Module: mod_xfer.c
- Module: mod_auth_unix.c
- Module: mod_auth_file.c
- Module: mod_auth.c
- Module: mod_ls.c
- Module: mod_log.c
- Module: mod_site.c
- Module: mod_ratio.c
- Module: mod_readme.c

Any help would be most appreciated. PCI Compliance has a deadline of June 30 and this is the only vulnerability standing between us and a clean audit.

Cheers,

Big Wil

[DirectAdmin Support]

Hello,

http://www.proftpd.org/docs/NEWS-1.2.10
Was their last "Stable" release.

Right on their main page, it also say "This module will be included in the next release of ProFTPD", which would be 1.3.0, wich isn't set as stable yet.

They do have a release candidate 1.3.0rc1, which would probably have what you're looking for.

I wouldn't say that not having the module is a huge security problem. Someone can just as easily see if a user exists by going to http://1.2.3.4/~username ;) (that's all this new module really hides anyway, which users exist or don't exist).

John

[BigWil]

John,

No it isn't a HUGE security problem. That kind of brute force attack is a rare animal anyways but it is still a possibility. Visa/MC/AMEX and Discover think it is a big deal though. So I do have to give it the attention it needs.

Any chance you can apply the LSS fix for it to the sources.

---snip---
Pseudo-random usleep() at the login procedure that will obfuscate time leak. Something like this:

proftpd-1.2.10/modules/mod_auth.c

1867a1868,1877

> {
> unsigned int randa;
> struct timeval tv;
> struct timezone tz;
> gettimeofday (&tv, &tz);
> srand(tv.tv_usec);
> randa = rand() % 20000;
> usleep(randa);
> }
>

After this simple patch is applied, it is impossible to tell which users do and don't exist:
---snip---

That is the fix that the auditing company is recommending anyways.

Cheers,

Big Wil

[webquarry]

So then updating proftpd using DA's rpms should just be a simple matter of grabbing the rpms for your particular linux flavor and then rpm -Uvh....?

Or did I miss something?

[jeffery]

DA uses a customized version.
Here are steps for update a CentOS 4 box:

#rpm -Uvh http://files.directadmin.com/services/proftpd-1.3.0rc3-1.src.rpm
#cd /usr/src/redhat/SPECS
#rpmbuild -bb --target=i686 proftpd.spec
#cd ../RPMS/i686
#rpm -Uvh proftpd-standalone-1.3.0rc3-1.i686.rpm
#rpm -Uvh proftpd-1.3.0rc3-1.i686.rpm
#/etc/init.d/proftpd restart

You should have rpm-build installed first, try yum install rpm-build

I have successfully updated to proftpd 1.3.0rc3 using the above steps. ;)

[webquarry]

Hi Jeff

I figured that grabbing the source rpms would be safe. I was trying to save people the extra step when I observed that DA seems to have put .rpm files in the various unix flavors on files.directadmin.com/services. I'm guessing that those are prebuilt and safe to install provided that you get the right one for your flavor of unix.

Can anyone at DA confirm this?