• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved Plesk Rouncube and exploit CVE-2023-5631

M-Ruiter

New Pleskian
Looks like Roundcube is still at version 1.6.0 with latest plesk installations while only version 1.6.4 will fix this.
 
Plesk plans to update Roundcube to version 1.6.4, respectively 1.4.15 where this is not possible due to operating system limitations, in the upcoming release 18.0.57 which is scheduled for the middle of November.
 
Mid-November?

This is a security vulnerability that is already being exploited!

What's wrong with you?

You should fix / roll this out in a few hours!

With little understanding
Stephan Schröder
 
  • Like
Reactions: B_P
Hello together,
I assume when you ensure that you run the latest roundcube 1.6.3 shipped by plesk packages, that you should be able to implement the following changes manually that should be overwritten automatically as soon as plesk ships 1.6.4 (You may better wait for an official confirmation from the Plesk Team that this is save to be done or not):

All changes necessary can be found in the link below, so locate the files, back them up in a folder outside of it's original location and then apply the small changes and you should be good to go.
2 Files should be modified, where maybe the first one is enough, as the test directory sounds to me like it might be just used as auto test during package creation, but as I never packaged roundcube myself, you better change both to be sure:
- program/lib/Roundcube/rcube_washtml.php
- tests/Framework/Washtml.php

Changes needed can be copy and pasted from here:

Best regards
Flashdown - A simple Plesk user running Debian
 
Hello together,
I assume when you ensure that you run the latest roundcube 1.6.3 shipped by plesk packages, that you should be able to implement the following changes manually that should be overwritten automatically as soon as plesk ships 1.6.4 (You may better wait for an official confirmation from the Plesk Team that this is save to be done or not):

All changes necessary can be found in the link below, so locate the files, back them up in a folder outside of it's original location and then apply the small changes and you should be good to go.
2 Files should be modified, where maybe the first one is enough, as the test directory sounds to me like it might be just used as auto test during package creation, but as I never packaged roundcube myself, you better change both to be sure:
- program/lib/Roundcube/rcube_washtml.php
- tests/Framework/Washtml.php

Changes needed can be copy and pasted from here:

Best regards
Flashdown - A simple Plesk user running Debian

I guess this would be a quick fix on any 18.0.56 Update #1 system:

Code:
mv /usr/share/psa-roundcube/program/lib/Roundcube/rcube_washtml.php /usr/share/psa-roundcube/program/lib/Roundcube/rcube_washtml.php_bck
wget https://raw.githubusercontent.com/roundcube/roundcubemail/master/program/lib/Roundcube/rcube_washtml.php -P /usr/share/psa-roundcube/program/lib/Roundcube/
 
I guess this would be a quick fix on any 18.0.56 Update #1 system:

Code:
mv /usr/share/psa-roundcube/program/lib/Roundcube/rcube_washtml.php /usr/share/psa-roundcube/program/lib/Roundcube/rcube_washtml.php_bck
wget https://raw.githubusercontent.com/roundcube/roundcubemail/master/program/lib/Roundcube/rcube_washtml.php -P /usr/share/psa-roundcube/program/lib/Roundcube/
Well this looks dangerous to me.

Why?
-> First of all you are getting the file from the current master branch, usually when a version is released then this branch will be used for the next version, so this is what makes it dangerous in terms of possible incompatibilities.

Next, I didnt check if there where further changes done to this file between version 1.6.3 and 1.6.4 so there could be incompatible changes in it. This is why I suggested to do these changes for fixing the CVE manually once, if you check it yourself and find no other changes beeing done in this file, then you can grab it via the commit I am referring to, otherwise do it manually once and then you have a file to deploy.

Also creating the backup file in the same location is not that good as you will forget about this file and it will remain forever. The Debian Package Management Systems keeps track of the files coming from a Debian package and ensures this doesnt happen. Therefore better put the backup file into /root/

Also you are moving the old original file away, thus losing the current permissions, user and group assigned to it. So better copy the file for backup away and keep the original in it's place, then just override the file with cp and the permissions, user and group will remain.
 
Please wait on the official update. Staff is already preparing it, and it will come very soon, probably within the next few days.
... coming back to the discussion of the annual price increase. With the price increases we have seen since Plesk has been bought by WebPros, customers expect an excellent support.
An update "within the next few days" for a vulnerability (where a known fix in terms of an available update for an open source component exists) is clearly NOT what falls under excellent support. Anything > 24 hours is not acceptable here.
 
@B_P Sorry to hear that this is still not fast enough for you. Which other vendors do you know who have fixed this vulnerability in their panels faster? Are you aware that for similar issues, e.g. with smartphone operating systems and apps, with office software, popular email apps etc. such vulnerabilities normally take weeks to be fixed? Is the expectation of an instant fix realistic?
 
Well this looks dangerous to me.

Why?
-> First of all you are getting the file from the current master branch, usually when a version is released then this branch will be used for the next version, so this is what makes it dangerous in terms of possible incompatibilities.

Next, I didnt check if there where further changes done to this file between version 1.6.3 and 1.6.4 so there could be incompatible changes in it. This is why I suggested to do these changes for fixing the CVE manually once, if you check it yourself and find no other changes beeing done in this file, then you can grab it via the commit I am referring to, otherwise do it manually once and then you have a file to deploy.

Also creating the backup file in the same location is not that good as you will forget about this file and it will remain forever. The Debian Package Management Systems keeps track of the files coming from a Debian package and ensures this doesnt happen. Therefore better put the backup file into /root/

Also you are moving the old original file away, thus losing the current permissions, user and group assigned to it. So better copy the file for backup away and keep the original in it's place, then just override the file with cp and the permissions, user and group will remain.

I have checked it and there where no further changes between 1.6.3 and 1.6.4 so you can apply the patch on 18.0.56 Update #1 by running this, at your own risk as I did:

cp /usr/share/psa-roundcube/program/lib/Roundcube/rcube_washtml.php /root/ cd /root/ && wget https://raw.githubusercontent.com/roundcube/roundcubemail/6ee6e7ae301e165e2b2cb703edf75552e5376613/program/lib/Roundcube/rcube_washtml.php && cp rcube_washtml.php.1 /usr/share/psa-roundcube/program/lib/Roundcube/rcube_washtml.php && echo done
 
Back
Top