On Thu, 13 Nov 2003 02:18:57 PST, Jeremiah Cornelius said: > > > We need to test it before we are permitted to upgrade. Please help. > > Help yourself and redesign your patch management. > Yeah. Everyone can do that, smartass.
No, he's right. The OP's environment apparently requires that there be testing before they're allowed to upgrade. That's *broken*. Plain and simple. "Testing can reveal the presence of flaws, but not their absence" - Dijkstra. How many people have trouble getting *known* *good* exploits to run in their environment? Now think hard here - if the exploit *works*, then yes, you have a problem. But if it doesn't work, *it doesn't prove the problem is actually fixed*. So you end up in a situation where you have *known* vulnerable boxes, and a fix to install, and the fix isn't being installed because you're busy trying to verify if the patch actually works, or if you simply have a defective exploit that would have worked if you had used gcc 2.96 instead of gcc 3.3 (a *known* issue for a lot of exploits), or if you had too many environment variables and something moved around in memory, or.... So let's see.. We have a fix from the vendor/maintainer that is claimed to fix the problem. The canned exploit doesn't work. Now, it's POSSIBLE that your exploit is b0rked, the fix didn't work, and if you changed something the exploit would work. Now how much effort are you going to put in to that testing (assuming that you're qualified to do it), while you have vulnerable machines in production? *That* is why the OP's patching scheme is broken.
pgp00000.pgp
Description: PGP signature
