Security

moe

ok, i've finally found the time to take this little beast for a ride
first off, nice job, installation was painless.

one detail is in urgent need for some polish, though:

vanilla, like any other php-script, should not *ever* write under it's own
document-root and consequently shouldn't have write-access there.
suggestions like "chmod 666" in the installation manual are very bad.

instead:

1. state'n'stuff that vanilla only needs internally should go under /var/tmp or /var/state
2. dynamic stuff that must be served by the webserver (avatars or somesuch?)
should go under a single dedicated directory which should be separate
from the vanilla tree (where the php files live). it should not be a
subdirectory in the vanilla tree.

the latter directory must be protected in the apache.conf via Options NoExec etc.
and vanilla should *verify* that no scripts can be executed from any writable
directory (e.g. by writing a small php-script that triggers an alert if it gets executed and have a "test-security" button in the admin interface point to it... or something like that...).

you don't want small bugs to turn into security holes, do you?


ps: after editing this post 5 times or so... what was the reason for not having preview in the core again?

lech

The only thing that isn't necessary is the chmod 757 or 755 of the images directory, however I will agree that the appg folder could be moved out of the vanilla tree. However there would then be no other way to save settings without these files having read/write access. They can't be executed remotely and don't print anything that could be considered a security risk, they simply store the global settings for vanilla. Mark would be better off explaining the ins and outs of how this works. But I don't see much of a security risk there unless another user on your domain is sharing access where vanilla is setup. The most I could see being split off from the settings is the DB info, which could be stored somewhere else.

Mark

Believe it or not, I'm still relatively new to *nix systems, and the permissions have been a bit of a trouble for me to get used to. However, I was planning on changing the chmod permissions for the next rev by refining it down to particular files and instead of chmodding, chowning to the apache user. As a matter of fact, there will be a number of other modifications to Vanilla that will make it more secure for the next rev - not the least of which being the isolating of filesystem access points. However, while I agree with your ideas in theory, the reality is that a very large portion of the people downloading and installing Vanilla will not have the luxury of putting Vanilla anywhere other than in a web-accessable folder. We can't all be system administrators, and Vanilla was built with *that* in mind as well. So, my plan is to keep the filesystem access points confined to a single folder within the vanilla tree, but recommend to users that they move that folder outside the web accessable tree for added security. Finally, remember that Vanilla is still in pre-version-one state. If you take a look at the bug list you'll see that there's still some road ahead. So, thanks for the suggestions, and keep checking back - we're getting to it :)

moe

They can't be executed remotely and don't print anything that could be considered a security risk

The problem is not with what these files are supposed to contain, the problem is what a malicious user could make vanilla (or PHP) write there.

Never have your webapp write to *any* executable location.

ps: and configuration and settings should ofcourse live in the database!

lech

moe, if memory serves correctly, NONE of the folders are given executable privs, in fact I should change the installation docs to remove that little 757 chmod. The only setting by default, when creating a new folder should be 755, owner rwx, everyone else has read access. So in that aspect, it's fairly safe unless the owner grants a higher permission. The files however would need a slightly higher permission to allow the "nobody" user (which in most cases php is run under) to write to the files. This is relativly safe.

moe

@mark yup, i hear you and please take no offense. i'm not trying to be rude, just please don't make the mistakes dozens of others made before. i'm one of the poor souls who frequently have to clean up the mess after clueless "admins"... a good compromise would probably this: 1. have vanilla under public_html/vanilla/*.php 2. have writable stuff under public_html/writable_stuff/* (separate from the php files!) 3. do not rewrite your own config files, store config data in the database 4. the only runtime config taken from a php file should be the dbserver credentials 5. tell in big red letters in the install manual that the "writable_stuff" directory must be set NoExec in apache 6. have vanilla check that the "writable_stuff" dir is actually NoExec as said, you could for example write a small piece of php there and redirect to it. if it executes it should display a very rude message and ideally lock vanilla down until the problem is fixed. these measures are really not overkill, i'm not just trying to scare you. php-worms nowadays work like this (simplified): a) kiddy finds bug in xyz.php (e.g. call it with special parameters and it will open a shell or "just" deface the site) b) kiddy writes up a small script that takes over a forum c) kiddy googles for "vanilla version x" and compiles a loooong list of victims d) kiddy launches it okay, enough ranting, i think you get my point :)

moe

@lech apache by default doesn't care for the unix exec bit unless you tell it to. apache only cares for its configuration and the very unfornationate "default" for most "php hosting providers" is to have it execute *.php whenever it stumbles over one. so, if someone can trick vanilla or php to write a file with .php suffix in the doc area then apache will obey and run it... the dangerous part is that vanilla can (and does) write to folders where apache will exec php files. ps: i'm not very familar with php but i assume the config files are just plain PHP files that get included? if that's the case then a malicious user might also try to inject his code right there.

lech

ahh, alright, I see what you're saying then. Yeah, makes sense then in many cases.

nathan

@moe (all of them): I am also a system admin (for a medium sized hosting company). I have seen a few vanilla installations get set up on my servers, and, I really can't see a problem. I have already raised the chmod 757 issue with mark and lech, and the documentation will be changed as soon as they get time (I might change the wiki now). If the file/ folder permissions remain the same as the ORIGINAL install recommendations, then I think we're safe. Mark can make no garatee that the user will follow these instructions, and then it is not his/ our problem. I understand where you are coming from, with regards to moving the writtable folders out of the vanilla tree. BUT, as mark has already stated, not everyone is a system admin. If someone in this position wishes to install vanilla in the root directory (public_html/), then they don't have the option (luxury) to move the writtable foldersoutside of the web accessable directory. I aggree with Mark, in that we leave it as it is, but have a suggestion in the doc, for those who can, to move it out of a web accessable directory. I have found no security problems (major ones) have you? Unless you write an extension that opens one up, I see no problems at the moment. PHP can't be executed within a vanilla comment can it? Don't think so.

moe

@nathan

then they don't have the option (luxury) to move the writtable foldersoutside of the web accessable directory.

i think generally you can always have two directories under your public_html and use a custom .htaccess to secure them? not luxury, standard apache mechanism!

I have found no security problems (major ones) have you? Unless you write an extension that opens one up, I see no problems at the moment.
PHP can't be executed within a vanilla comment can it? Don't think so.

There will be security problems. The extensions codebase is not under mark's control so a loosely written extension may very well open doors even if the core is safe. PHP has had its share of own security problems, too.

The question is not whether it happens but how much impact it causes when it happens.

Mark

i hear you and please take no offense.

None taken!

3. do not rewrite your own config files, store config data in the database

There is absolutely no way I am going to load these settings (which are practically constants) from the database. I've said it before and I'll say it again, the biggest hole for performance loss is in database queries. I use as few queries as possible in Vanilla and I plan on keeping it that way. Worst case scenario: I remove the application settings form and make the users edit their settings.php file manually.

PHP can't be executed within a vanilla comment can it?

No.

The extensions codebase is not under mark's control so a loosely written extension may very well open doors even if the core is safe.

That is my biggest concern with extensions.

lech

@nathan : I already changed the wiki docs to reflect the 757 permissions, I did leave it as a "rare case scenario" note though.

nathan

@lech: Thanks. I saw that. I understand the extensions can open up vulnerabilities, but, is that really our problem? I don't think so. If some moron tries to piece together an extension and it mistakingly gives access to the database, then that is THIER problem and not ours. You would have a check on the extensions page that has a look for any COMMON/ FAMILIAR vulnerabilities and warns the user if one is detected.

lech

If some moron tries to piece together an extension and it mistakingly gives access to the database, then that is THIER problem and not ours.

Well, if you think about that in the context of the community setting, it is as much our fault as it is theirs if that extension is linked here as well. But yeah, it's the admins fault for installing it in the first place, and the writers responsibility for maintaining security in mind. If it's some undisclosed extension we don't know about, then yeah, it's totally the users fault.

nathan

I did not actually mean ones located on the wiki, but, come to think of it, we should have a discalimer (for marks sake), saying that these are community contributed extensions and that lussumo takes no responibility for them, or the consequences of using them.

lech

true.

moe

@nathan

well, it's a matter of attitude but i think if you expect many of your users to be less tech savvy then it would be wise to implement all possible security precautions.
if vanilla ever gets compromised (through extensions or not) then it gets a bad name. well, actually it is then considered equal to almost any other forum package out there. just google for "$your_fav_forum_name exploit" and count the bugtraq listings per product. it's not funny anymore...
the other thing is that currently i cannot easily audit vanilla because of this gaping hole. if vanilla didn't have write-permission to exec'able directories then i'd only have to grep for exec() and other dangerous php functions and know i'm safe if they don't show up in the codebase.
but since vanilla *can* write to exec'able dirs code-injection is possible and
my codebase is potentially much larger than i would like

@mark

There is absolutely no way I am going to load these settings (which are practically constants) from the database. I've said it before and I'll say it again, the biggest hole for performance loss is in database queries.

hummm. doesn't php know runtime static vars?
in other languages you would basically fetch the values from the db once (on startup or first hit) and then have them in memory. when they are changed you flush the changes to the db.

i'm ofcourse not proposing to fetch them on every hit!

lech

The one absolute thing I can think of that would need to remain in the settings.php are the database host, db name, user and login. Otherwise we're talking about locking our keys in the car here.

moe

@lech yup, the db host must stay in there (or in some php config file). actually you can store whatever you like there, important (security-wise) is only that vanilla must not have write access to these files. a work-around might be to not "include" the files but actually read() them, so php code doesn't get interpreted. i don't think it's worth the hassle though considering the other advantages you get from moving config stuff to the db.

lech

@moe: Well, if you look at it, the only potentially harm that could come to you, is if your DB data was leaked out somehow. The only significant harm that could come to the board, is if the cookie domain info was changed (that's changed in the next rev from what I'm told). The other data there isn't much of a concern whether it's in the DB or in a flatfile, it's mostly insignificant. Don't get me wrong, I like security as much as everyone else, but I think mark has taken the necessary steps to secure this information very well. It's not as if someone can generate a full blown script through any of these controls at the moment, and most if not all of the inputs are filtered to prevent such action, mark should confirm that though in case I'm wrong. One of the users here was going to run a vulnerability test, but I haven't seen or heard of any results as of yet. By all means, take your own installation and attempt to hack into it from user level and see what you can come up with and notify mark of any significant threats. I really don't see this as too big of a deal if vanilla is reading/writing to only 2-3 files it's allowed to and nothing more. I've tried running admin commands of reading/writing to files on my own setup and so far have not been able to sucessfully do any damage. The most damage I was able to do was in the form of a master admin by deleting my own admin role. So far, there's only 6 instances of the fwrite command found across 3 files, as long as the reigns of these functions remain under tight control, I can't really see how someone from the outside could map their way into doing some calculated harm. Then again, I could be wrong.

Minisweeper

I'm not up on security aspects, but i dont really see how vanilla having write access creates a security hole unless i've completely misunderstood the security settings and this somehow gives anyone browsing the forum the ability to rewrite the rewriteable files themselves and then make them execute? In any case i guess it would make more sense to move the settings files to below the www directory just to make sure security was at its best. Unless it is majorly flawed though, i agree with mark that performance should be a big factor and that if using a database is really so much slower, it should be avoided at all costs.