I vote 1 as well. The problem only occurs if the function is used insecurely by the developer. There are a few functions which are implemented insecurely a lot. Since these holes are always the same, hackers will try to use this. So fixing 90% of the problems would not leave the hacker with enough other ways to hack the site, but effectively prevent at least 90% (and probably more) of the stream hacks. As a shared hosting company I would be very happy when there would be 1hack per year instead of 1 hack per month.
When we design a system we hold on to the idea that no system is perfectly secure, but you can make hacking a lot more difficult by patching the biggest and best known holes first. PS. I've had no response on the offer/request to have a look at our kernel patch and apache module to switch the user of the running process. Is nobody interested after all? If we make it open source, we first want others to confirm that it good. Best regards, Arnold Alain Williams wrote: > On Thu, Jan 18, 2007 at 01:13:51AM -0800, Stanislav Malyshev wrote: > >>> I am with Arnold on this one. Implement a patch that fixes the source of >>> most of >>> the problems, tidy the rest at leisure. Better to get an effective fix >>> quickly >>> than wait forever for perfection. >>> >> Security solution can't plug 90% of holes and then leave the rest for >> leisure... Effective fix means fixing all problems, not just 90% of it. >> > > The choice appears to be: > > 1) Fix for 90% of compromises, wait forever for fix for the last 10% > 2) Wait forever for fix for 100% of compromises > > I vote (1). > >
