ProFTPD patch is not working

[Marcel Zuidwijk]

After receiving this mail: http://www.parallels.com/products/plesk/ProFTPD
I've done the advised patch:

# wget -O - http://www.atomicorp.com/installers/atomic |sh
# yum upgrade psa-proftpd

Now is my FTP not working any more. Well, it is working for local users created on linux.
But clients cannot logon with FTP on their domein. They receive the message 'Access denied'.

How can I remove this upgrade/patch? I want to get it undone....

I also receive a error when updating through the update manager:

A dependency problem is found: required package psa-proftpd-xinetd-1.3.1-fc7.build93091230.06.i586 conflicts with psa-proftpd-1.3.3c-2.fc7.art.i386. No upgrade or obsolete solution was found for psa-proftpd. Try to add psa-proftpd to removable list.Problem occured during searching conflicts for package psa-proftpd-xinetd-1.3.1-fc7.build93091230.06.i586 ERROR: Unable to proceed with the installation until the package psa-proftpd-1.3.3c-2.fc7.art.i386 is removed from the system.

Removing it, will trigger to remove more packaged, what isn't wanted:

Dependencies Resolved

=============================================================================
Package Arch Version Repository Size
=============================================================================
Removing:
psa-proftpd i386 1.3.3c-2.fc7.art installed 5.8 M
Removing for dependencies:
SSHTerm noarch 0.2.2-9.278624 installed 4.9 M
miva-ssl-stub i386 1.0.1-0.91137 installed 3.5 k
plesk-billing noarch 6.0.4-20090625.11 installed 42 M
psa i586 9.3.0-fc7.build93091230.06 installed 30 M
psa-api-rpc noarch 9.3.0-fc7.build93091230.06 installed 1.4 M
psa-atis i386 1.0-50 installed 635 k
psa-atmail noarch 1:1.02-fc7.build93091230.06 installed 6.8 M
psa-awstats-configurator noarch 1.0.0-fc7.build93091230.06 installed 0.0
psa-backup-manager i586 9.3.0-fc7.build93091230.06 installed 11 M
psa-fileserver i586 1.0.0-fc7.build93091230.06 installed 692 k
psa-firewall i586 1.0.1-fc7.build93091230.06 installed 555 k
psa-hotfix1-9.3.0 i586 9.3.0-fc7.build93100518.17 installed 19 k
psa-hotfix3-9.2.3 i586 9.2.3-fc7.build92091210.11 installed 79 k
psa-kav i386 1.0.0-fc7.build93091230.06 installed 8.5 M
psa-libpam-plesk i586 9.3.0-fc7.build93091230.06 installed 153 k
psa-locale-nl-NL noarch 9.3.0-2009121411 installed 10 M
psa-migration-agents i586 9.3.0-fc7.build93091230.06 installed 138 k
psa-migration-manager i586 9.3.0-fc7.build93091230.06 installed 949 k
psa-miva i586 9.3.0-fc7.build93091230.06 installed 4.5 M
psa-rubyrails-configurator i586 1.1.6-fc7.build93091230.06 installed 0.0
psa-spamassassin i586 9.3.0-fc7.build93091230.06 installed 161 k
psa-tomcat-configurator noarch 9.3.0-fc7.build93091230.06 installed 0.0
psa-updates noarch 9.3.0-fc7.build93100518.17 installed 0.0
psa-vpn i586 2.0.1-fc7.build93091230.06 installed 2.2 M
psa-watchdog i586 2.0.3-fc7.build93091230.06 installed 3.4 M

Transaction Summary
=============================================================================
Install 0 Package(s)
Update 0 Package(s)
Remove 26 Package(s)

Is this ok [y/N]:

How can I solve this?

 

[trialot]

Marcel,

Next time, first check the upgrade scripts (and if not clear, do not use them).

Currently, your solution can be found in two ways:

A - apply the hotfix from Parallels and keep track of the psa-proftpd file (if needed, replace appropriate proftpd files)
B - download source files of proftpd 1.3.3c and compile in a separate directory and symlink the following files:
- /usr/sbin/in.proftpd to compiled proftpd
- /usr/bin/ftp*** files (like ftpwho, ftpcount etc) to compiled ftp*** files

First try A, only then try B (and read my update on this solution).

Kind regards....

 

[Marcel Zuidwijk]

Thnx for the reply ... is it possible to upgrade to Plesk 9.5.3 to solve this?

 

[trialot]

Marcel,

I am checking the autoinstaller and I see that the micro update (i.e. hotfix) is included.

To be sure, run autoinstaller from a ssh console and follow the installation process when upgrading, you should see that the micro update is included in the download and installation process.

Kind regards...

 

[Marcel Zuidwijk]

rpm -i --force psa-proftpd-1.3.1-fc7.build93091230.06.i586.rpm

Did the trick for me... Ok, I'm vulnerable, but at least FTP works again...

 

[trialot]

I am not sure what you are doing, but you uninstalled the psa-proftpd.

In order to resolve vulnerabilities:
- Just upgrade the version of psa-proftpd and apply the current hotfix

 

[Marcel Zuidwijk]

I am not sure what you are doing, but you uninstalled the psa-proftpd.

In order to resolve vulnerabilities:
- Just upgrade the version of psa-proftpd and apply the current hotfix

I forced to install the latest default base package...

FTP is working, now I can spent more time in fixing it

# rpm -q psa-proftpd
psa-proftpd-1.3.3c-2.fc7.art
psa-proftpd-1.3.1-fc7.build93091230.06
# rpm -e psa-proftpd-1.3.3c-2.fc7.art
error: Failed dependencies:
psa-proftpd-start is needed by (installed) psa-9.3.0-fc7.build93091230.06.i586
# rpm -q psa-proftpd-start
package psa-proftpd-start is not installed

 

[MiguelG]

I'm using Plesk 9.5.3 and i'm having the same problem. ¿where can i download the hotfix? Using the updater in Plesk panel doesn't solve the issue (the updater fails to install the base plesk package)

regards,

 

[trialot]

Marcel,

The problems you have are the result of the atomic upgrade.

The .art files are problematic and the problem seems to be found in the missing psa-proftpd-start file (how did that happen????? That should not be common with the atomic upgrade).

Can you be more specific about the successes/failures (on psa-proftpd or proftpd) when upgrading the panel to 9.5.3. version, so I can be of assistance?

Note: the fact that you cannot remove .art files due to missing dependencies is not problematic, since the hoftix/panel upgrade should overwrite the files installed by .art. Manually remove all remaining .art files.

And, just mail me if required.

Kind regards.....

 

[jpplante]

Has anyone applied the patch to a Suse Enterprise server yet?

The "Hotfix" targets Redhat only.

 

[trialot]

Remark

Has anyone applied the patch to a Suse Enterprise server yet?

The "Hotfix" targets Redhat only.

The official hotfix from parallels also does work on Suse Enterprise Server (SLES).

Presumably, you have installed the atomic upgrade fix, that can yield problems for SLES in two ways:
I - not installing a hotfix (since atomic upgrade is not targeting it), but that is not a problem: if NO files are installed, use the Parallels autoinstaller and apply the official hotfix,
II - installing some files that prevent installation of the official Parallels hotfix and cannot be uninstalled easily (just delete manually)

Kind regards....

 

[jpplante]

Thank you for the response. I apologize but do not quite understand what you mean.

I have an SLES 10 server running 9.53 (I just updated this morning), I have not applied any patch at all for the ProFTP issue. I was wondering the procedure I would use to patch this vulnerability. The directions that were sent to me utilize the Atomic fix. I downloaded the link but again It refers to RedHat only using "YUM" which of course I am not running RedHat. Again thanks for your response and if you have any additional information It will be greatly appreciated.

 

[jpplante]

trialot,

Thanks again, I understand what your post meant now. It appears my system is now patched by the official patch and not the atomic patch. Again I appreciate your response.

 

[xurubo93]

I am unsure if the patch was applied. I can see that the microupdates has been downloaded and the filesize and the date of proftd in the download directory is the same as in /usr/sbin/proftpd, but proftp -v gives me the same version no as before: 1.3.2e

I thought that this vulnerability has been solved in 1.3.3c so I am quite unsure if this patch was applied.

 

[MiguelG]

I am unsure if the patch was applied. I can see that the microupdates has been downloaded and the filesize and the date of proftd in the download directory is the same as in /usr/sbin/proftpd, but proftp -v gives me the same version no as before: 1.3.2e

I thought that this vulnerability has been solved in 1.3.3c so I am quite unsure if this patch was applied.

Yes, it's solved, please refer to this thread to read more details: http://forum.parallels.com/showpost.php?p=428406&postcount=66

 

[trialot]

I am unsure if the patch was applied. I can see that the microupdates has been downloaded and the filesize and the date of proftd in the download directory is the same as in /usr/sbin/proftpd, but proftp -v gives me the same version no as before: 1.3.2e

I thought that this vulnerability has been solved in 1.3.3c so I am quite unsure if this patch was applied.

Xurubo,

Take it for granted: the hotfix has been applied if you can see that is downloaded and installed.

Parallels uses a unfortunate naming convention in the hotfix: psa-proftpd is of version 1.3.2e, being a compiled version of proftpd 1.3.3c, that includes a patch for the security issue.

So, no worries, you are safe.

 

[Jonas21]

@trialot: That is not true. Parallels doesnt use 1.3.3c. They instead use a patched 1.3.2e.
Most vendors (linux distribution maintainers) do this. They do not use newer versions as originally released to avoid conflicts because of newer features/changed syntax etc.
To make sure you have a patched 1.3.2e you can either check the timestamp of /usr/sbin/proftpd (should be November) or try the exploit on your server.

 

[trialot]

Correct

@trialot: That is not true. Parallels doesnt use 1.3.3c. They instead use a patched 1.3.2e.
Most vendors (linux distribution maintainers) do this. They do not use newer versions as originally released to avoid conflicts because of newer features/changed syntax etc.
To make sure you have a patched 1.3.2e you can either check the timestamp of /usr/sbin/proftpd (should be November) or try the exploit on your server.

Jonas21,

In a formal sense, you are correct. It is indeed a patched version of the old proftpd.

I found that out this morning, too my surprise, since the patched 1.3.2e is able to read newer (1.3.3c) versions of the scoreboard, for example.

I did some additional checks and found out that scoreboard (among others) is again run as version 1.3.2e.

From that perspective,you are right.

The patches applied however, do seem to make the patched 1.3.2e invariant to 1.3.3c or 1.3.2e proftpd output.

That makes it even more surprising why Parallels did not hotfix psa-proftpd to proftpd version 1.3.3c.

No big problem though, since it is possible to upgrade various components of Plesk Panel to newer versions, without any problem. Tomcat, proftpd etc, they can run (almost without exception) on newer version than the variants supplied by Plesk.

Jonas21, perhaps you have any idea what Parallels exactly patched in source code of proftpd?

Needless to say, vulnerability of proftpd is not limited to the telnet iac issue (currently hotfixed).

But then again, saying that or saying that Plesk hotfixes version 1.3.2e (unfortunate naming convention, incorrectly indicating vulnerability that is not present when hotfixed) is making people scared.

And that was the reason I did not mention this, when discovering it this morning ..........but still, you are correct.

Kind regards....

 

[Jonas21]

I think the scoreboard-format didnt change that much, so its compatible with 1.3.3c. They could have also patched the changes into 1.3.2e but i dont really think that would be usefull/make sense.
If you check the changelog for proftpd you will see that there are quite some changes since 1.3.2e->1.3.3c. Maybe they just didnt want to risk having something not working with the newer version or they were in a rush and just wanted to get this fixed.
I have no idea which other patches Parallels includes in their version of proftpd.

Sure you can update to newer versions yourself...works almost all the time. It just depends if the component has some "magic" feature that was added by Parallels to have it perform better with Plesk or add some type of feature (account, whatever).

They only way to exactly find out what was change is to either get the source from Parallels (unlikely) or disassemble the proftpd version (via IDA or similar).

In my opinion proftpd is a pretty dangerous thing....there are quite some other daemons out there which do offer the same functionality but do not have such a bad history of (remote) vulnerabilities. One example is vsftpd (very secure ftpd). I would love if Parallels would think about migrating to it. Its written with security in mind and not one-trillion features which probably noone needs and are maintained (or rather not maintained) by ten thousand people.

The problem with the naming convention is a usual thing. Everyone does it...as previously posted. If you have a "dumb" vulnerability scanner like nessus or alike you will always get false positives this way.
Again in my opinion the best way is to remove the name branding of proftpd/make it "hello" with just "FTP Server ready".
This way it makes it far more difficult for someone from the outside to find out which ftp server is actually running and if it is vulnerable.

Just my 2 cents...