Roundcube exploit

dlong500

Verified User
Joined
Nov 16, 2004
Messages
80
I know that there is already a thread or two about the recent Roundcube exploit (and that it was apparently fixed in the latest 0.2 stable release), but I feel it is worth mentioning that you can be hit by this exploit even if you used Custombuild and chose not to install/manage Roundcube.

DirectAdmin apparently installs the Roundcube application (as well as the other webmail apps) even if you chose not to install/manage them in the Custombuild script. The script is a little ambiguous, because when I went through it just several days ago I was under the impression that if I disabled Roundcube in the Custombuild script that it would not be installed at all. Fast-forward to today and I got hit by the exploit, so I went in and immediately deleted the Roundcube folders. And yes, I used Custombuild from the start (no previous install of DirectAdmin on the server).

Is the current version of DirectAdmin still shipping with a vulnerable version of Roundcube? If so this should be updated immediately, and even better would be to actually not install the webmail applications unless specifically chosen in the Custombuild script.
 
Last edited:
i think custombuild is just let you choose to update it or not to update it.
 
i think custombuild is just let you choose to update it or not to update it.

Yes, that is clear to me now, but I think it would be great to a least have an option for Custombuild to actually remove those applications. It's always a good idea to be as secure as possible in the default configuration. For that matter, it would probably be a good idea for DirectAdmin to have some install options in the install script that force you to choose to install something like Roundcube rather than have it there by default.
 
well, they didn't know Roundcube has exploit, any script can have exploits, if you want to have least software installed, just go ahead remove them manually, that's what I do with my servers, I removed roundcube, atmail and modify some other stuff that may cause security issues. DA don't secure the server for you, you need to do that manually.
 
Is there a way to enable DA updates of Roundcube, Squirrelmail, etc on custombuild?
 
well, they didn't know Roundcube has exploit, any script can have exploits, if you want to have least software installed, just go ahead remove them manually

It doesn't matter if a software provider knows what components have vulnerabilities or not. That's the whole point of not having components installed by default that are not core to the application. If an optional component has a security hole and it isn't installed by default then your userbase won't have that security hole by by default. And of course I have removed the components manually on my own server now, but my comments are general in nature and are addressing how DirectAdmin can be more security friendly for everyone in the future.

DA don't secure the server for you, you need to do that manually.

I'm not asking DA to secure my server. And I'm not even blaming DA for this exploit. But I am suggesting ways to make the default install more secure. Feel free to give reasons to the contrary, but I don't see how an option to not install optional components would be a bad thing.
 
Is there a way to enable DA updates of Roundcube, Squirrelmail, etc on custombuild?

Yes there is. Just enable the management of them in the options.conf file:
Code:
#Web applications
phpmyadmin=yes
atmail=no
squirrelmail=no
roundcube=no

uebimiau=no

And then make sure you are running "./build update" to make sure you have the latest version DirectAdmin offers.

However, this does not mean that DirectAdmin will always have the latest version of the software available. Sometimes there is a day or more that goes by before DirectAdmin updates their repositories.
 
It doesn't matter if a software provider knows what components have vulnerabilities or not. That's the whole point of not having components installed by default that are not core to the application. If an optional component has a security hole and it isn't installed by default then your userbase won't have that security hole by by default. And of course I have removed the components manually on my own server now, but my comments are general in nature and are addressing how DirectAdmin can be more security friendly for everyone in the future.



I'm not asking DA to secure my server. And I'm not even blaming DA for this exploit. But I am suggesting ways to make the default install more secure. Feel free to give reasons to the contrary, but I don't see how an option to not install optional components would be a bad thing.


some people don't see roundcube as optional. they use it to replace squirrelmail and UebiMiau.
 
some people don't see roundcube as optional. they use it to replace squirrelmail and UebiMiau.

Look, the fact that some people view Roundcube as essential to their services doesn't make it a required component. It is, by definition, optional if DirectAdmin can run without it. I'm not trying to tell you that you can't use Roundcube, but rather just offering suggestions that would benefit the DirectAdmin userbase as a whole. Would it really be that hard for you if you had to type "Yes" during an install to include Roundcube?
 
if that's the case, then DA should make other things optional too, like squirrelmail and UebiMiau, atmail and even phpmyadmin. they all can have exploits.
i still don't understand why those people would get hacked by this exploit if they have the server secured. DA by default install is not secure at all, especially with suphp, i posted couple threads regarding default installation security issues before but seems nobody care about it. :(
 
I mentioned in my previous posts that I'm referring to all optional components, not just Roundcube. Again, I'm not talking only about this specific exploit but the nature of vulnerabilities in general.

And I don't follow your logic when you say that you "don't understand" why people would "get hacked" if they have their server secured. Server security is not a Yes or No, black or white issue. No one can ever expect 100% security without unplugging their server from the Internet. Being secure means using a set of security tools, properly configuring those tools, and practicing a methodology that minimizes risks by doing things like not installing components that you don't use.

And while there may be some security tools and configurations that could minimize the effects of this exploit, from what I've read you are vulnerable if you have a version of Roundcube before 0.2 stable. Period. So if I use your logic then being "secure" means not having a pre-0.2 final version of Roundcube installed at all, which brings me back to my original suggestion of having DA NOT INSTALL OPTIONAL COMPONENTS BY DEFAULT.
 
Last edited:
by securing I mean secure php, such as disable_functions, openbase_dir, /tmp, chmod 750 to wget, scp, etc...
these are basic stuff, if you have done that, that exploit shouldn't do much damage.

anyways i understand what you want, i'm not saying have the option to choose is a bad idea, i just want to say people should focus on securing their servers more.
 
The main problem is when you update roundcube, phpmyadmin, directadmin leaves the old installation in /var/ww/html. With the ip adress/roundcube-0-1.1 you can still access the old installation of roundcube,
 
The main problem is when you update roundcube, phpmyadmin, directadmin leaves the old installation in /var/ww/html. With the ip adress/roundcube-0-1.1 you can still access the old installation of roundcube,

No, it does not if you have clean_old_webapps set to "yes" in the options.conf.
 
The main problem is when you update roundcube, phpmyadmin, directadmin leaves the old installation in /var/ww/html. With the ip adress/roundcube-0-1.1 you can still access the old installation of roundcube,

AFAIK the way you get to webapps in the standard apache2 configuration is through the 'Alias' in /etc/httpd/conf/extra/httpd-alias.conf. Which is always a symlink to the particular version. This means 1) you can only get at the linked version and 2) rm <symlink> closes the door. And just to be sure, it is easy enough check it and make sure you get the 404....
 
by securing I mean secure php, such as disable_functions, openbase_dir, /tmp, chmod 750 to wget, scp, etc...
these are basic stuff, if you have done that, that exploit shouldn't do much damage.

Can you or anyone else here tell us how to secure /tmp on a VPS?
 
The only way to secure /tmp is for it to be on its own partition. If its not on its own partition then its too late unless you still have free unpartitioned space on the hard drive or in the case of a vps, virtual hard drive.
 
On most systems you can mount an image as if it were a partition, in *nixes for example by using a special loopback device through 'mount -o loop'.
There are plently of tutorials about doing this on the web, you just have to ask All Mighty Google.
 
Well I've got 30GB but it looks like it's all partitioned to /dev/simfs or something like that... :(
 
Back
Top