Hi
When (some) expected rpm package for the upgrade php to version 5.2.5(CentOS4) ? Who knows?
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
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
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.
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
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
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
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.
security@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
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.
security@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, 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
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
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*
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:
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!
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 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.
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.
Jim Perrin wrote:
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.
am in the process of bringing that into centosplus :D
On Mon, 14 Jan 2008 11:10:17 +0100 Ralph Angenendt ra+centos@br-online.de wrote:
Mark Weaver wrote:
I personally can think of no reason at all for php-cli.php-pear needs it. Why php itself depends on it isn't clear to me either.
Cheers,
Ralph
that in and of itself bothers me.
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.
-
Barry Brimer -
Chris Mauritz -
Jim Perrin -
Johnny Hughes -
Joshua Baker-LePain -
Karanbir Singh -
Mark Weaver -
Ralph Angenendt -
Ray Van Dolson -
Santa Claus