RoundCube 1.2.3 released

DirectAdmin Support

Administrator
Staff member
Joined
Feb 27, 2003
Messages
9,158
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
 
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:
Code:
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/
 
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
 
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!
 
Back
Top