Hacking and security - what is the ultimate htaccess?

Hacking and security - what is the ultimate htaccess?

by Timothy Takemoto -
Number of replies: 16

Ah, the generic recommended .htaccess file that comes with moodle is moodle/lib/htaccess, and the contents are here
http://xref.moodle.org/nav.html?lib/htaccess.source.html
And it is explained here
http://docs.moodle.org/en/Installing_Moodle#Using_a_.htaccess_file_for_webserver_and_PHP_settings

It includes (which are already set on my server) except for the last two of which I can find no mention.
php_flag magic_quotes_gpc        1
php_flag magic_quotes_runtime    0
php_flag register_globals        0
php_flag file_uploads            1
php_flag short_open_tag          1
php_flag session.auto_start      0
php_flag session.bug_compat_warn 0

There is no mention of
php_flag allow_url_fopen   0
so perhaps it is not needed.

Elsewhere Oliver Kuy reccomends the following .htaccess for 1&1 Servers
upload_max_filesize = 20M;
browscap = /usr/local/lib/browscap.ini;
error_reporting = (E_ALL & ~E_NOTICE & ~E_WARNING);
url_rewriter.tags = "a=href,area=href,frame=src,form=fakeentry,fieldset=";
register_globals = off;
allow_url_fopen = off;
max_execution_time = 50000;
safe_mode = off;
file_uploads = on;
magic_quotes_gpc = on;
memory_limit = 41943040;
short_open_tag = on;
post_max_size = 26214400;

This page has all sorts of information about using .htaccess to increase security.

For example, I thought that the following might be a good idea to remove the threat of malware in the following languages.
RemoveHandler cgi-script .pl .py .cgi
AddType text/plain .pl .py .cgi

Limiting ip addresses to ones country (Japan in my case) is almost impossible as ip addresses are all over the place and some international. But some Japanese do it with a very long htaccess file which one can base on this but I will not be doing it.

Conversely, we are warned against using htaccess for the reasons explained here
http://httpd.apache.org/docs/1.3/howto/htaccess.html#when
but since allowoveride does seem to be set on my server, meaning that apache is looking for htaccess files, the only drawback seems to be the need to download the file, which is very short at the moment. But perhaps even a short htaccess is better avoided.

I am just trying to think of ways to improve security on an old moodle version, since upgrading is not easily possible and I don't know what to patch.

Average of ratings: -
In reply to Timothy Takemoto

Re: Hacking and security - what is the ultimate htaccess?

by Mauno Korpelainen -

Good points, Timothy.

Those posts were from the time when allow_url_fopen had to be on or moodle would have had problems with translations and some other things. It was just recently fixed so that installing moodle does not fail if allow_url_fopen is off:

http://tracker.moodle.org/browse/MDL-2555

http://tracker.moodle.org/browse/MDL-16123

http://tracker.moodle.org/browse/MDL-8758

Default setting of php 5 is OFF for allow_url_fopen and under some conditions (if script is producing php output and user input is not properly sanitized) it might have been possible to use XSS attacks against moodle sites - I don't know if any such attacks have been possible, Petr might know better the old vulnerabilities.

Anyway it is safer to have that setting off if moodle otherwise works ok - and I suppose core code of moodle has been doublechecked to be secure even if allow_url_fopen is on.

Average of ratings: -
In reply to Mauno Korpelainen

Re: Hacking and security - what is the ultimate htaccess?

by Mauno Korpelainen -

Talking about continuous checking of all code a fresh example:

www.phpbb.com was hacked a week ago and is still down ( 400000+ account details intercepted ! )

http://www.suspekt.org/2009/02/06/some-facts-about-the-phplist-vulnerability-and-the-phpbbcom-hack/ expains why it was possible even when register_globals was off...

Average of ratings: -
In reply to Mauno Korpelainen

Re: Hacking and security - what is the ultimate htaccess?

by Timothy Takemoto -

Wow, PHPBB....that is big news.

Both this PHPBB hack and the Joomla hack seemed to exploit register_globals emulation. Does or did moodle ever emulate register_globals in a similarly exploitable way?

My moodle is 1.6.2/3 and and upgrading is not really an option.

The PHPBB hack recommends "activating open_basedir" so would it improve security to add php_variable open_basedir = moodleroot or dataroot?

Tim



Average of ratings: -
In reply to Timothy Takemoto

Re: Hacking and security - what is the ultimate htaccess?

by Mauno Korpelainen -

No as far as I know core files have never done it - but I took that as an example of using code of other open source projects and how the vulnerable code should be noticed and patched before crackers have time to get the benefit of "new" security holes. You never know how secure the code of 3rd party plugins is and people like Petr simply can't check all the things that we want to embed or include to core code. Or some settings that used to be on for years may be found vulnerable and should be off... and all the code needs to be checked again. And new vulnerabilities are found almost daily from browsers, php, mysql, phpmyadmin or other programs we use.

I don't know if even open_basedir restriction is enought - open_basedir was designed to stop PHP scripts from accessing files outside the open_basedir restrictions but it does not prevent attacks inside open_basedir folders. You would need to add both dataroot and dirroot to open_basedir and still some virus or hidden script inside uploaded fake image might launch attack if permissions allow writing or executing files and might be able to rewrite and bypass the 'open_basedir' restriction. Maybe we just need to face the fact that a functional learning environment where people can upload files and write to database is always less secure than a solid web site where nothing changes. And reading http://www.darkreading.com/blog/archives/2009/02/phpbb_password.html confirms that most students and teachers (sometimes even administrators) don't care about properly selected passwords or use the same usernames and passwords everywhere... admin, test and 12345...

I suppose upgrading your moodle at least from 1.6.2/3 to 1.6.9 (latest) should be possible also in your case - or have you customized the original code so much that any attempt to upgrade breaks the whole site? Or moving course backups to a newer parallel moodle without any changes to old moodle untill all courses have been moved safely.

Average of ratings: -
In reply to Mauno Korpelainen

Re: Hacking and security - what is the ultimate htaccess?

by Timothy Takemoto -

The biggest problem with upgrade is the lack of a particular module in later versions.

But I think that 1.6.9 is a possibility. Yes I have customised the code so it will take a while.

If there were a simple htaccess file that would help tighten up security, then  I am not sure of the drawback, other than the very small speed loss.

At the moment I have
open_basedir = "/xyz/public_html/moodle;/xyz/data"
php_flag allow_url_fopen   0
php_flag register_globals  0

Average of ratings: -
In reply to Timothy Takemoto

Re: Hacking and security - what is the ultimate htaccess?

by Petr Skoda -
Picture of Core developers Picture of Documentation writers Picture of Peer reviewers Picture of Plugin developers
"My moodle is 1.6.2/3 and and upgrading is not really an option."

This is sad and not responsible at all. Please upgrade to at least latest 1.6.x. Hacking configuration files does not help at all.

We used to have similar globals hack, but luckily it was removed in 1.6.0.
Average of ratings: Useful (2)
In reply to Petr Skoda

Re: Hacking and security - what is the ultimate htaccess?

by Timothy Takemoto -

Dear Petr Skoda

Thank you for all your work on moodle security. I am sorry to sadden you.

> Hacking configuration files does not help at all.
I was thinking of adding a .htaccess file rather than hacking anything.  Do you think that adding a .htaccess file containing
open_basedir = "/xyz/moodle;/xyz/data"
php_flag allow_url_fopen   0
php_flag register_globals  0
would be no help at all?

I have however hacked my moodle installation extensively which would make upgrading to 1.6.9 a burden.

It would help me, and I believe many other moodle administrators, if there instructions on how to patch old systems but I appreciate that to publish such instructions would be  burden.

And possibly a security risk?

I don't think that it would be a security risk. Should you find the time to publish a "how to patch your moodle for security" guide, then I and others would, I believe, be very grateful.

Thank you again for your work on Moodle security,

Tim

Average of ratings: -
In reply to Timothy Takemoto

Re: Hacking and security - what is the ultimate htaccess?

by Timothy Takemoto -
I can tell tha Petr Skoda is busy.

Can anyone else share their thoughts the merits patches to make older moodle systems secure (rather than upgrading).

One problem seems to me that people would be less inclined to upgrade to the latest versions and thus less inclined to submit bug reports on ongoing Moodle development.

Tim
Average of ratings: -
In reply to Timothy Takemoto

Re: Hacking and security - what is the ultimate htaccess?

by Petr Skoda -
Picture of Core developers Picture of Documentation writers Picture of Peer reviewers Picture of Plugin developers
Back from vacation wink

Well, you either have to upgrade to latest release or manually patch all security issues. There is no other way, sorry!

Please note that backporting of security patches into ancient releases is not always easy because sometimes we have to make extensive changes or the fixes rely on seemingly unrelated changes done in previous releases.

If you want to limit the results of hacking use some virtualised server solution and install only one web application on each server. Do not forget to backup often the complete server image and restore immediately if you notice any problems.

You can find the settings recommended by php developers in every windows PHP package - see file php.ini-recommended, Moodle specific recommended changes are in installation docs.

Petr
Average of ratings: -
In reply to Petr Skoda

Re: Hacking and security - what is the ultimate htaccess?

by Timothy Takemoto -

Dear Petr

Welcome back. I hope you enjoyed your vacation.

I am afraid I am not able to change php.ini, set a local php.ini or set up a virtualised server. I have little control over my server. So if I wanted to affect changes to the server then it would be via .htaccess.

Also I was thinking of adding things that are not recommended by moodle at present (such as turning off all cgi scripts other than php) to tighten up security even more than would be necessary on a fully up to date system.

I agree that I would have to manually patch all security issues, but despite the fact that someone (possibly you) sent me an automated search link to security issues on the 1.6.x path in the bug-tracker, I was unable to decifer what changes needed to be made. (In fact I could not find any security issues that were relevant. The only one I understood was for the blogs, which I do not use)

If the patchers were in the form
1) to fix security issue A which affects systems that are using modules BC and D
In moodle/xyz/abc.php at about line n
change
XXXXXXXXXXX
to
YYYYYYYYYYYYYYYY
and
then of course, I would be able to patch no problem.

By the way, I am still using Windows and Word 2000. I would like to write a blog entry "in praise of not-upgrading" (I bet it has been written already) I would include things like
1) Most of the new features will not be useful to you.
2) You will not be able to use the added features anyway
3) The added features will place an extra processing and memory burden upon your system.
4) The learning curve just to use the features you have been using is not worth it.
5) The added security provided by the later version is offset by the security dangers invovled in upgrading itself, and in the fact that you will be less likely to be able to use the new and unfamiliar system in a secure way.
etc. Well....I only mean to point out that there are plusses and minuses.

Googling for "of not upgrading" yeilds "risks," "(hidden) costs," "drawbacks" and this image
http://www.flickr.com/photos/karafraser/3107722440/

Tim

Average of ratings: -
In reply to Timothy Takemoto

Odp: Re: Hacking and security - what is the ultimate htaccess?

by Bartosz Cisek -
After reading this thread I think that you stay on opposite sides of 'upgrade problem'.

Petr try to force people to upgrade to most current version (current does not mean stable), Tim try do stay too long with tested and working solution.

I can't understand why there is no real stable version of Moodle. Stable in terms of 'Debian stable' -- no new features, no improvements, no new bugs, just bugfixes.

Now, if I want secure Moodle platform I have to update to newest one, with bugfixes, but also with a bunch of new features, impovments, and new bugs. Why?

I think it's much broader problem, look at Linux kernel, there is no dev/stable distinction, as it used to be between 2.4.x and 2.5.x branch. Just look at commercial distros like RHEL or SuSe. RHEL5.3 (current) stick with 2.6.18 kernel (with backported bugfixes) while there is 2.6.28.x on kernel.org repo. Why? because RHEL long distance goal is to provide stable software that can solve problems, not that you would continously repair. The same with GNU/Debian.

If Moodle has ambition to become serious project for large Universitis, it should have more serious Q&A policy.

Solutions? Maintain one branch, stable branch, frozen one, only bugfixes. Second branch for those who like more adrenalin during morning coffe.

One may say, there is 1.9.x stable and 2.0-dev branches, what do you want more? Well, just look into bugtracker and see how many improvements were intruduced since 1.9.0 release. Can you guarantee that no new bugs were introduced with them? Security fixes are only made in HEAD. So it's fake stability.

I like Moodle, I use it a lot, and all my criticism is lead by care about future development.

Bartek
Average of ratings: -
In reply to Bartosz Cisek

Re: Odp: Re: Hacking and security - what is the ultimate htaccess?

by Iñaki Arenaza -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Security fixes are only made in HEAD. So it's fake stability.

This is not so. All security fixes made into HEAD and the last stable release at least (in fact, most of them make it into the two last stable releases).

Wrt to the Linux development model as opposed to the Moodle development model, perhaps there's a business opportunity there smile (after all, that's part of the reasons distros exist wrt to the kernel).

Saludos. Iñaki.

Average of ratings: -
In reply to Iñaki Arenaza

Odp: Re: Odp: Re: Hacking and security - what is the ultimate htaccess?

by Bartosz Cisek -
Hello Iñaki,

Well, I checked, two recent security issues published by Petr XSS atack and CSRF in forum code. Fixes both appeared in 1.9.4, great. But what about 1.9.0, 1.9.1, 1.9.2 and 1.9.3? You may say that last digit is to inform about bugfix release, and we should stick to the latest one.

Reliability curve shows that most of problems occure at the firs stage of product life. That's why constantly adding new features is not what should be done to maintain stability.

So upgrading to lastes 1.9.x apart from bugfixes user has to include also several new features. This stays in strong oposition to reliability theory, that says, bugs should be removed, not included with new features.

This lead to situations where we couldn't export/import quiz question between two moodle instacnes that differed 14 days (same major and minor numbers), because export format was extended by one column.

I don't want to complain. Disclaimers about using OpenSource on my own risk are well known. The point is that such Q&A policy, has strong influence on code quality and user good or bad experience.

In my humble opinion Moodle code management should be at least improved.

kind regards,

Bartek
Average of ratings: -
In reply to Bartosz Cisek

Re: Odp: Re: Hacking and security - what is the ultimate htaccess?

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Every additional branch we maintain is a lot of extra work for all developers. Therefore, it is necessary to reach the most practical compromise between the number of branches we maintain.

In theory, what we do is have HEAD, which is were the development of all new features happens, and which is currently working towards Moodle 2.0, and a number of sable branches. Normally four active stable branches, but for various reasons, at the moment we are only supporting the 1.9.x and and 1.8.x branches. In theory, those stable branches are bug and security fixes only, but again that is too simplistic.

For example, at the moment we are still quite a long way from the Moodle 2.0 release, and there are new privacy laws in the US and Europe that made it difficult to use Moodle in a lot of institutions. Therefore, it was decided to implement a bunch of new privacy features on the 1.9.x stable branch becuase it was judged that they could be introduced with minimal risk, and also with administration settings so they could be turned off by default, and so only administrators who needed them and turned them on, would notice any difference in their Moodle site.

So, the rule with stable branches is, they should be bug and security fixes only, except when we have a sufficiently good reason to make an exception.


On the subject of regressions caused by bug fixes and new features. Again, you have to make the most pragmatic compromise. If you insist that no new code is added to Moodle unless it is thoroughly reviewed and tested to the point where everyone is convinced that there are no new bugs, then development would virtually grind to a halt. It is actually more efficient to take a more relaxed approach; for developers to take reasonable precautions as the developer, and to do a reasonable amount of testing before committing; to do only after-commit code review via the CVS commit email address; to allocate some time for testing (Development:Weekly_Code_Review); and as payment for faster development, to accept a small number of regressions that are found and fixed quickly.


So, altogether, our development processes are a compromise to try to deliver as much as possible of what we think our users want as quickly as possible with the resources we have while maintaining a reasonably high level of stability. It is something we thing about a lot, talk about and adjust. So, it is a bit messy, but it seems to get the job done. Welcome to the real world.
Average of ratings: Useful (1)
In reply to Tim Hunt

Odp: Re: Odp: Re: Hacking and security - what is the ultimate htaccess?

by Bartosz Cisek -
Hi Tim,

Thank you for reply. I understand that Moodle developers constantly try to keep proper ratio between including new features and improving stability. But this model might be improved to give users a choice.

Once again I recall Debian project, where IMHO stability management is on very high level. Using this analogy,
  • 2.0 branch might be 'unstable' where almost everything is possible, new features, not always working
  • 1.9 might be testing where new features are introduced, but on terms you mentioned: there is serious reason to do so.
  • 1.8 might be stable where only bug and security fixes are possible.
This is real world example that gives users simple to understand message, about what each version can be used for. Moreover this model gives user a choice, between stable, but more or less old, features and more current features but with possibility of problems and experimental package with no warranty at all.

What do you think about this possibility?
Average of ratings: -
In reply to Timothy Takemoto

Re: Hacking and security - what is the ultimate htaccess?

by Mauno Korpelainen -

I moved the whole old thread to Security and Privacy forum.

Is there any need to update documentation about .htaccess and allow_url_fopen, Petr?

Average of ratings: -