From: Paul L. <pa...@sq...> - 2008-01-04 04:01:21
Attachments:
secured_configuration.diff
|
All (esp. Jon?), Per my last message to this list regarding mobile phone compatibility, I am thinking about the plan we have to add no-cookies support to the DEVEL stream. Jon earlier sent a message with an brief outline of an idea to add a function that will auto-generate correct URIs that will have the session name added to them. Because the "key" is also stored in a cookie, we'll also need to add the key to the URI. That makes me cringe, because that makes the key much, much easier for an attacker to sniff. The alternative is to just keep the key in the user SESSION on the server, so it never goes over the wire. However, this makes it easy to snag the user's IMAP password for anyone who has access to the server (particularly PHP's session storage location), and an attacker can get the password a little easier if they can hijack a user's session, whereas currently, they ALSO have to hijack the key cookie. Therefore, I think that also it's a lot less than ideal, the best choice is to keep the key on the client side just like we do now, albeit passed back and forth via the URI instead of a cookie. The subject of this message is not actually about the implementation of that mechanism, as I think it is straight-forward. What I want to propose is that we will want to have a configuration setting that turns cookie support on and off. BUT, because of the extra security risk involved in running SM without cookie support, we'll want to "guard" that configuration setting. One way to do this is to hard-code the way in which we retrieve this config setting from the config.php file. However: configuration variables in SM can currently be overridden if an attacker can get someone to install a rogue plugin or if there is some other dangerous PHP code running on the server. Because SM's register_globals sanitization routine means that this last concern is (I hope) near impossible, because the chances that this kind of rogue code (plugin) running are small (assuming the admin is competent), and because in some cases, a setting like "cookie support" may need to be changed on the fly (we want to "unguard" the setting sometimes), I believe it is acceptable to instead achieve a "guarded" configuration state dynamically: There can be another configuration setting that I am calling "secured_config". It *IS* always retrieved in such a way that it comes directly from the config.php (or config_local.php) and can never be overridden by a plugin or any other code. The configuration variable for cookie support would be accessed either in a "guarded" manner or not, depending on the value of "secured_config". It would have to be coded slightly differently because of how it is accessed, but that seems fine, as it marks the setting very clearly as one that is potentially "secured" or "guarded". My proposed implementation is done in such a way that we can "guard" any value from the configuration file that we may determine to be one that is a potential security risk. The disadvantage is that each such variable will incur exactly one extra load of the config (and config_local) file for each page request (if it is used in that page request). Also, while this "secured configuration" mode for SquirrelMail might please some sysadmins, in fact, those kinds of people will have little need for it since they won't be running untrusted code in the first place. A "secured" or "guarded" config setting would be accessed in the code like this: $cookie_support = get_secured_config_value('cookie_support'); if (!$cookie_support) { // now do something like append the key and session name to the URI } I'll add this to SVN unless someone has some objections. See the attached patch. Cheers, Paul |
From: Daniel W. <d...@ni...> - 2008-01-04 14:08:00
|
[snip] > What I want to > propose is that we will want to have a configuration setting that > turns cookie support on and off. BUT, because of the extra security > risk involved in running SM without cookie support, we'll want to > "guard" that configuration setting. One way to do this is to > hard-code the way in which we retrieve this config setting from the > config.php file. However: configuration variables in SM can currently > be overridden if an attacker can get someone to install a rogue plugin > or if there is some other dangerous PHP code running on the server. [snip] Bear with me - trying to follow this through but not sure I understand 100%. Do you mean that plugins will not be able to turn cookies on and off at all? Because I would, ideally, like to vary the cookie support setting with the vlogin plugin. I have one code instance of squirrelmail on the server and use vlogin to vary the configuration. I have a virtualdomains array in vlogin which contains a particular domain wap.domain.com that does stuff like disable the logo and preview pane and it is here that I would like to turn off the cookie requirement. Would that still work? Thanks Paul. |
From: Paul L. <pa...@sq...> - 2008-01-04 18:25:23
|
On Jan 4, 2008 6:13 AM, Daniel Watts <d...@ni...> wrote: > [snip] > > > What I want to > > propose is that we will want to have a configuration setting that > > turns cookie support on and off. BUT, because of the extra security > > risk involved in running SM without cookie support, we'll want to > > "guard" that configuration setting. One way to do this is to > > hard-code the way in which we retrieve this config setting from the > > config.php file. However: configuration variables in SM can currently > > be overridden if an attacker can get someone to install a rogue plugin > > or if there is some other dangerous PHP code running on the server. > > [snip] > > Bear with me - trying to follow this through but not sure I understand > 100%. Do you mean that plugins will not be able to turn cookies on and > off at all? Because I would, ideally, like to vary the cookie support > setting with the vlogin plugin. > > I have one code instance of squirrelmail on the server and use vlogin to > vary the configuration. > > I have a virtualdomains array in vlogin which contains a particular > domain wap.domain.com that does stuff like disable the logo and preview > pane and it is here that I would like to turn off the cookie > requirement. Would that still work? Yes, with my proposal it would. The scenario you describe is exactly one of the reasons that I proposed having the ability to turn the "secured configuration" on and off. |