[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