@lech 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).
hmm. sorry but i think i don't understand. when someone manages to exec code on my machine it generally means that the box is lost. it means the host has to be wiped and reinstalled because it may be under the control of some kid in taiwan.
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.
The main problem I see is the extensions codebase.
With write-access (as of now) the broken ext can be abused to write a crafted PHP-file and take the shell. Without write access the broken ext will not be able to inject code.
I guess it's all about the level of paranoia you want to apply... As you may have guessed I prefer maximum paranoia over "clean the mess later"
yeah moe but i think what lech is saying is that (besides extensions which is a whole different basket of eggs), vanilla as standard doesnt allow for a kiddie to exec something on your server.
I dont see how without running every extension through some sort of security checking (which probably isnt such a bad idea) you're gonna be able to stop extensions having the ability to take over your server. After all any php file with a few sly uses of exec() can do quite a bit of damage, but this file would have had to be introduced to the server by the admin of the forum in which case its their responsibility.
I'm with moe here. Security should be the number one. Many forum admins don't like their forums because of security breaks and patches all the time. It get's annoying. Vanilla could stand out of the bulk of the usual forums. Not only on usability.
IF write access isn't used very often, how hard would it be to swap out the data into a database. Perhaps values could be cached, held in session on the server or something. I''m not familiar enough with PHP as I have a stronger Java web applications background, but it should be possible to hold important data values per session on the server. So read access is fast and access to the database isn't required too often. Am I wrong?
With write-access (as of now) the broken ext can be abused to write a crafted PHP-file and take the shell. Without write access the broken ext will not be able to inject code.
I am in absolute agreement with you there, moe. That right now is the only concern of mine personally. At the moment, to my knowledge, there isn't a universal safe read/write global command so any extensions that might need it, will need to craft their own. While I'm not against crafting my own, anyone using say another extension as a template to perform this function could wind up introducing flaws if say the original extension is doing it wrong, or if it becomes accessable to a user of a lesser role that shouldn't have access to it in the first place. Otherwise as far as Global Application Settings is concerned, it's locked down rather tight.
Mark's probably gonna hate me for bringing this up... But I wouldn't mind confining those 6 fwrite functions down to one or two as part of a smart read/write library which only gets called as needed. This library being not just for Vanilla, but extensions as well which in the future might be doing more read/write functions than Vanilla itself. This is in the case of say the Language editor or any remote upgrading (if that happens to come up). While it's not necessarily the settings files I'm worried about vanilla writing to, it's more or less the actual DB and the keys to said DB that would bother me.
So wait, we're talking about the possibility that an extension gives the ability for a user to write to a php file as opposed to the extension itself? That makes more sense now..
After all any php file with a few sly uses of exec() can do quite a bit of damage
Yup, but its easy to grep for "exec" (and "eval" for that matter) over the whole installed codebase (incl extensions) and get rid of any extension that uses it.
I think it would be harder to trace all write-calls because many extensions will read/write files instead of using the database (which, imho, is a bad idea but it seems to be common practice in the PHP crowd). It just feels better to know that no part of vanilla, no matter how hard it tries, will be able to write to dangerous places (where code could be executed later) ever.
It's just one thing less to worry about... I don't care much if some bug allows an attacker to wipe my forum. But I start to care very much when a bug allows an attacker to run his shellcode and take over the whole box!
ps: ah.. i just saw your last reply after finishing my post. well, yes, that's my main concern (some bug in an ext allowing a malicious guy to inject his code somewhere)
lol, pay attention mini :D when improperly handled, the fwrite command if being fed filenames from an array or otherwise if not explicitly set and targeted to a specific file can be possibly tricked into writing entirely new files, or overwriting ones you don't want it to. That's the main concern when dealing with this type of security issue.
i was paying attention but i'm also trying to pretend i'm doing something worth being paid money for (stupid jobs) and when i dont fully understand stuff to begin with i get easily confused.
I was thinking more along the line that someone could rewrite or access the settings files and then run them since they were xx7'd (although i thought it was still not possible for non-unix-users which is why i was getting more confusing).
It all makes sense now..
Ahh, yeah, well in theory, the only current folder which has an elevated permission setting (which should be set back to normal after install) is the images directory. the settings, languages and extensions files only need and have a read/write setting so that only limits those files to reading/writing while everything else is relativly safe from any serious haxt0rbating. Plus those files upon inspection, accept only a certain number of safe characters as to not allow anything from slipping up.
mini, give me money!
I hate to reopen this old conversation but I came here hoping to find a way to store Vanilla configuration in the database rather than writing it to a file, and was dismayed to find that this came up five years ago and the situation still hasn't changed.
My concerns are security, which is well covered here, but also the ability to store my config file in version control, which is how the site is developed and deployed. Having the production app modify the config file on the server will inevitably cause file version conflicts when deploying changes.
So once again, can we please add a way to store config data in the database? Nearly every other CMS on earth does it this way. A single extra query to load this info will have basically no impact on performance, while this change will be a huge security and convenience win.
This discussion was about V1 but it's applicable to V2 as well.
Making the file read-only will improve security but introduce problems when making certain configuration changes on the public site. Messages, for example, are stored in the database but still requires writing to the config file. While they can be saved, the saving process appears to hang when the file isn't writable so it appears as if it's not saving. Making the file read-only is a work-around at best.
Comments
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).
hmm. sorry but i think i don't understand.
when someone manages to exec code on my machine it generally means that the box is lost. it means the host has to be wiped and reinstalled because it may be under the control of some kid in taiwan.
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.
The main problem I see is the extensions codebase.
With write-access (as of now) the broken ext can be abused to write a crafted PHP-file and take the shell. Without write access the broken ext will not be able to inject code.
I guess it's all about the level of paranoia you want to apply...
As you may have guessed I prefer maximum paranoia over "clean the mess later"
I am in absolute agreement with you there, moe. That right now is the only concern of mine personally. At the moment, to my knowledge, there isn't a universal safe read/write global command so any extensions that might need it, will need to craft their own. While I'm not against crafting my own, anyone using say another extension as a template to perform this function could wind up introducing flaws if say the original extension is doing it wrong, or if it becomes accessable to a user of a lesser role that shouldn't have access to it in the first place. Otherwise as far as Global Application Settings is concerned, it's locked down rather tight.
Mark's probably gonna hate me for bringing this up... But I wouldn't mind confining those 6 fwrite functions down to one or two as part of a smart read/write library which only gets called as needed. This library being not just for Vanilla, but extensions as well which in the future might be doing more read/write functions than Vanilla itself. This is in the case of say the Language editor or any remote upgrading (if that happens to come up). While it's not necessarily the settings files I'm worried about vanilla writing to, it's more or less the actual DB and the keys to said DB that would bother me.
After all any php file with a few sly uses of exec() can do quite a bit of damage
Yup, but its easy to grep for "exec" (and "eval" for that matter) over the whole installed codebase (incl extensions) and get rid of any extension that uses it.
I think it would be harder to trace all write-calls because many extensions will read/write files instead of using the database (which, imho, is a bad idea but it seems to be common practice in the PHP crowd).
It just feels better to know that no part of vanilla, no matter how hard it tries, will be able to write to dangerous places (where code could be executed later) ever.
It's just one thing less to worry about...
I don't care much if some bug allows an attacker to wipe my forum.
But I start to care very much when a bug allows an attacker to run his shellcode and take over the whole box!
ps: ah.. i just saw your last reply after finishing my post. well, yes, that's my main concern (some bug in an ext allowing a malicious guy to inject his code somewhere)
My concerns are security, which is well covered here, but also the ability to store my config file in version control, which is how the site is developed and deployed. Having the production app modify the config file on the server will inevitably cause file version conflicts when deploying changes.
So once again, can we please add a way to store config data in the database? Nearly every other CMS on earth does it this way. A single extra query to load this info will have basically no impact on performance, while this change will be a huge security and convenience win.
Why don't you simply make the file read-only?
Making the file read-only will improve security but introduce problems when making certain configuration changes on the public site. Messages, for example, are stored in the database but still requires writing to the config file. While they can be saved, the saving process appears to hang when the file isn't writable so it appears as if it's not saving. Making the file read-only is a work-around at best.