Our client subscribes to ScanAlert’s service (www.scanalert.com) to check for security problems.
We’ve recently received notification from ScanAlert that our server may be vulnerable to some PHP-related exploits, but this assertion is based on the fact that we’re running PHP 4.3.9 (which, if unpatched, would indeed be vulnerable). I would like to assume that the PHP package we have installed (php-4.3.9-3.32.5.vm) has all the relevant security patches applied, but I’m not sure where to look to confirm this.
What exactly is the ancestry of the PHP package I have? Where can I look to see what patches have been applied?
I’m running Virtualmin Professional on Red Hat Enterprise Linux 4.
Good for you for asking exactly the right question about the PHP package version.
The ancestry is exactly the same as for RHEL4, we just rebuild it with fastcgi support enabled (which Red Hat doesn’t do until their PHP 5 packages in RHEL5).
I believe the source should also be in our repository for all of the rebuilt packages, but I might be wrong (my build scripts keep changing and sometimes I break things).
Thanks for the swift response
It’s good to know that I can use the “errata” section of Red Hat’s site to make sure all the vulnerabilities have been patched.
For future reference: you say you build from CentOS packages, which trail Red Hat by a few days. That raises the question: how far behind CentOS are you?
We’re using mod_php rather than fastcgi on our server - I know this is a security risk in theory, but it’s somewhat mitigated by the fact that we only enable PHP for sites under our control. If we wanted to switch back to using Red Hat’s PHP packages, would we be able to do this fairly easily or would that risk later breakage?
One more question: is there a reason why your release number is 3.32.5 and Red Hat’s is 3.22.5? Bearing in mind you’re tacking the “.vm” on the end, it seems odd that the release numbers are different.
Incidentally, I just tried the forum’s “preview” feature and it seems to be slightly broken - the preview comes up with white text on a pale grey background, which is pretty much illegible.
For future reference: you say you build from CentOS packages, which trail Red Hat by a few days. That raises the question: how far behind CentOS are you?
Realistically? A few days. We do the best we can.
We're using mod_php rather than fastcgi on our server - I know this is a security risk in theory, but it's somewhat mitigated by the fact that we only enable PHP for sites under our control. If we wanted to switch back to using Red Hat's PHP packages, would we be able to do this fairly easily or would that risk later breakage?
Yes. mod_php works fine under the Red Hat packages. Just make sure you aren’t loading both php5 and php4 modules.
One more question: is there a reason why your release number is 3.32.5 and Red Hat's is 3.22.5? Bearing in mind you're tacking the ".vm" on the end, it seems odd that the release numbers are different.
For my own amusement. Actually, it’s just a simple way to make sure ours is newer than theirs without bumping the epoch. +10 is arbitrary, and maybe not high enough, but it’s working so far. If I get bitten by it too much I might switch over to epochs (which I do use on Apache, and a few others that would seriously impact what we’re doing if they reverted).
Incidentally, I just tried the forum's "preview" feature and it seems to be slightly broken - the preview comes up with white text on a pale grey background, which is pretty much illegible.
I know. It’s irritating. I’ll try to get it fixed soon (I’m a bit swamped at the moment with some regressions on Ubuntu, and working on Fedora 7 support, but I hope to be back to working on the website in a few days).
Realistically? A few days. We do the best we can. ;-)
Fair enough - I can't ask for more than that.
Yes. mod_php works fine under the Red Hat packages. Just make sure you aren't loading both php5 and php4 modules.
Understood; I know those modules won't coexist. We don't use PHP5 anyway, so no problem there. I think we'll stick with the Virtualmin packages for now, unless something really scary comes up.
For my own amusement. Actually, it's just a simple way to make sure ours is newer than theirs without bumping the epoch. +10 is arbitrary, and maybe not high enough, but it's working so far. If I get bitten by it too much I might switch over to epochs (which I do use on Apache, and a few others that would seriously impact what we're doing if they reverted).
I don't know enough about RPM to fully grok that explanation, but you seem to know what you're doing :-)
I know. It's irritating. I'll try to get it fixed soon (I'm a bit swamped at the moment with some regressions on Ubuntu, and working on Fedora 7 support, but I hope to be back to working on the website in a few days).
Sounds like you're wearing a number of hats - I feel your pain :-)
