PHP vulnerabilities?

Stuart Low stuart at serverpeak.com
Wed Dec 22 06:08:34 UTC 2004


> Forgive me if this message sounds a little tence, the bent of the
> conversation is a little worrying to me. It takes 100's and 100's of
> hours to certify an application such as mine on a new platform - those
> 100's and 100's of hours equate into a lot of money.

I don't want this to turn into a bitch session, however, if there have
been 100s of hours and consequently 1000s of dollars spent in getting
certification I would imagine that fixing a large number of issues with
newer PHP builds would be a minimal I.T. cost.

Perhaps it would be wise to suggest to your management team that without
at least some sort of timeline in place for catching your application up
with what is now 2 generations of PHP versions the application they run
(which is clearly mission critical and expensive) will become
incompatible with the software used to run it. The fact that PHP was
chosen in the first place suggests whoever made that decision would have
been wise to factor in the fact that PHP is still young and will and HAS
changed. If it had been C or Perl OTOH..

Personally, I agree with Michal. Sure, it may not have been worth
upgrading to suit 4.2.x but pretty soon you're going to be stuck with
PHP5 and then you're totally up s**t creek. When one produces a massive
application and has it certified they also accept the undertaking of
keeping it compatible with underlying changes with a concrete timeline
on when revisions should be done.

> Presumably the PHP 4.1 that is currently in fedora legacy has all of
> the previously known security issues addressed, although that might be
> an inacurate assummption. So of those 27 pages of changes since 4.1.2
> only the newly discovered problems are of great concern. Even if there
> are other security concerns lingering, this particular problem is
> remotely exploitable which makes it more pressing than most others.

In my industry (Hosting), ANY vulnerability is a bad one. Period.
There's no room to move and wasting time and resources on maintaining a
version of PHP which is well over 3 years (??) old, particularly when
you rely on someone working for free (which I believe the FL guys are,
correct me if I'm wrong) it just plain doesn't make sense.

If your application is worth so much perhaps you should consult with a
company who is PAID to maintain EOL distros (like RH7.3)? Like Progeny
for example? My bet though is that within a few years even those EOL
updaters will be EOLed. ;) 

> I have been testing with 4.3.8 and found numerous changes such as
> functions taking different params, functions being renamed, things
> that were marked as experimental in 4.1 stabilizing... you can imagine
> how these can have a dramatic effect on compatibility.

Yes, and I can imagine how easy they are to fix (generally speaking).
Allocate $X resources in the new year and step your application up so
that you don't have to worry about this sort of crap (updating a
deprecated version VS. a new release).

> Honestly, if I wanted newer versions of the software, I would upgrade.
> I need to use FL because I can't afford the instability of FC (Let me
> just point out that RedHat's EOL policy came out long after I'd made
> the decission to standardize on RH).

Instability of Fedora Core? Err.. Redhat has commercial offerings for a
REASON. RHEL3 is being maintained till 2008 I believe and cost aside,
there's a bunch of free RHEL3 rebuilds.

> I pray that some way can be found to ascertain if the problems apply
> to RH7.3 and if so, that a patch can be found and applied without
> changing the features of the PHP that is present.

The way I see it, a large majority of people will have no problems with
upgrading to the latest PHP. Perhaps those that do may wish to converse
with each other and pay a software developer to make the legacy changes.
Banks maintain their legacy Cobol applications through expensive and
limited Cobol developers.

There's 2 choices:

1) Upgrade your application to work with the new PHP (running it through
R&D appropriately).
2) Patch PHP with backported C .patch's.

(1) May seem harder now but in the long run (3-6 years) is in my opinion
smarter. (2) will be more expensive over a longer period of time.

Stuart




More information about the fedora-legacy-list mailing list