[horde] HORDE and PHP security issue(s)
Michael M Slusarz
slusarz at mail.curecanti.org
Tue Nov 1 14:30:19 PST 2005
Quoting brian at highstream.kicks-ass.org:
> I checked the list archives a bit and see almost no discussion of horde
> and security, is there a better list than this for security discussions?
> if so I couldn't find it.
>
> This newest vulnerability is kind of worrying:
>
> http://www.internetnews.com/dev-news/article.php/3560456
>
> and the linked to article here:
>
> http://www.hardened-php.net/index.76.html
>
> rm'ing/chmod'ing test.php and not having register_globals on in php.ini
> are a start but it seems like it's application specific as to what is safe
> or not. Thoughts, comments?
Horde makes sure (see lib/core.php) that no globals are defined at the
beginning of a page load if register_globals is set. so this should
not be an issue. (and test.php does make very clear that
register_globals should not be set)
For any of the other PHP exploits - obviously Horde will be as
vulnerable as every other PHP application since these are PHP core
issues, not usercode issues. Naturally we don't workaround these
exploits since, up to a short time ago, *nobody* realized these
exploits existed.
Obviously the solution is to upgrade PHP. This is not a Horde issue.
> I know the answer is upgrade php but I have some production servers with
> HUGE horde prefs dbs that take a considerable amount of time to dump and
> restore if/when something goes wrong. All you admins know people go nuts
> if their mail is down for any amount of time.
Why do you need to dump/restore DB? Your DB backend is completely
independent of PHP. Upgrading PHP from 4.4.0 to 4.4.1 should be a
simple matter of recompiling/updating the PHP binaries and associated
libraries. You should not need to touch anything in Horde/IMP after
the update.
michael
_______________________________________
Michael Slusarz [slusarz at curecanti.org]
More information about the horde
mailing list