RoundCube 1.2.3 released

[DirectAdmin Support]

Hello,

RoundCube 1.2.3 has been released and added to files1.
Release notes:
https://roundcube.net/news/2016/11/28/updates-1.2.3-and-1.1.7-released

I've also re-packaged it to include httpdsocket class version 3.1 which uses curl calls, rather than fosckopen, because php 5.6+ is picky about certifiates, and curl lets us ignore self-signed certs. fsockopen +php 5.6+ does not let us ignore them, and throws errors. Curl will be a bit friendlier anywa, with regards to timeouts, and RFC compliance, etc...

John

 

[Harry Tang]

Thanks.

Can you check/fix this: http://forum.directadmin.com/showthread.php?t=53857

 

[ditto]

Thanks.

Can you check/fix this: http://forum.directadmin.com/showthread.php?t=53857

Have you upgraded Roundube? If so please let us know. Do not ask for a fix before you have tested the newest version.

 

[Harry Tang]

upgraded, tested (also tested with new fresh installed DA), problem still exist.

 

[tomputer]

Roundcube 1.2.3 fixes a security issue[1][2], for which it uses the escapeshellarg PHP function[3]. However, this function is disabled by default in the PHP disable_functions.

The default disable_functions are included in this file:

usr/local/lib/php.conf.d/50-webapps.ini

So Rouncube on DirectAdmin is still vulnerable for this fix.

Is there a way to remove it from the 50-webapps.ini file without getting overwritten again by DirectAdmin? Or maybe this should be removed as by default from the disable_functions?

[1] https://roundcube.net/news/2016/11/28/updates-1.2.3-and-1.1.7-released
[2] https://github.com/roundcube/roundcubemail/commit/f84233785ddeed01445fc855f3ae1e8a62f167e1
[3] https://blog.ripstech.com/2016/roundcube-command-execution-via-email/

 

[DirectAdmin Support]

Hello,

Removal of escapeshellargs can be open for discussion. The function itself isn't really a security risk, as from what I can read, it's only a string modifier.
The mentioned vulnerability requires RoundCube to use the mail() method.
We do not have RoundCube setup this way (we use smtp on port 587), so the issue wouldn't affect a DA install of RoundCube.

Also to say the RC would still be vulnerable wouldn't be entirely accurate, because if the function is blocked php would likely throw an error and the mail() method would simply be blocked entire via that php call simply not working

So for now, we should be able to leave it as it is, without the security issue nor broken functionality.

John

 

[tomputer]

Also to say the RC would still be vulnerable wouldn't be entirely accurate, because if the function is blocked php would likely throw an error and the mail() method would simply be blocked entire via that php call simply not working

You're right about that, sorry, my bad.

So for now, we should be able to leave it as it is, without the security issue nor broken functionality.

Great! Thank you for your reply!