On 12/28/2011 02:01 PM, Bennett Haselton wrote: > Yeah I know that most break-ins do happen using third-party web apps; > fortunately the servers I'm running don't have or need any of those. > > But then what about what my friend said: > "For example, there was a while back ( ~march ) a kernel exploit that > affected CentOS / RHEL. The patch came after 1-2 weeks of the security > announcement. The initial > announcement provided a simple work around until the new version is > released." > Is that an extremely rare freak occurrence? Or are you just saying it's > rare *compared* to breakins using web apps? Or am I misunderstanding what > my friend was referring to in the above paragraph? Yes, that is rare. There *are* holes in nearly everything, though, and there are workarounds and patches for nearly all of those holes. But not all holes are equal. Not nearly so. For example, the vast majority of the security announcements for RHEL are rated as very minor, despite the enormous scrutiny Linux is subjected to. That we can find SO MANY tiny holes is a testament to the thoroughness of the community approach to common component development (which is a bit different from the dynamic found in niche applications development, despite what the RHSs of the world have to say). It is important to ask your friend two things: 1- Was the vendor involved in the announcement, and if so was the workaround explained thoroughly in the announcement and permit reconfiguration of a functional system? Sometimes people want to make a name for themselves by "finding a hole in the Linux kernel" and try to announce things without notifying the vendor, in which case the bad guys and good guys have a race to see who will develop first, the patchers or the exploiters. Even IBM can get caught off-guard by things like this with Big Adult systems like z/OS. Being caught off-guard is the problem Google tries to solve by providing both paying and stroking the ego of people who find security problems with their infrastructure. Preventing the malicious use of such information is what the whole "Full Disclosure" concept is about (though the mailing list of the same name is often just nothing more than trollville) 2- Did the security hole, when exploited, grant root access? Without the ability to root the machine, the picture is a lot less grim. Understanding iptables, SELinux, what apps are installed, what Apache modules aren't necessary (quite a few), etc. can go a long way to providing intermediate barriers against a big scary hole in the kernel. Consider that the kernel has one huge hole by design called root. Getting access to it is the key, and the vast majority of security announcements permit marginal, not root, system access. To answer your original question, the "announcement in March" is not anything I heard of. Or more correctly it isn't something I remember in particular, and I tend to keep up with things. I hear about *lots* of security holes in lots of different software daily. Most of it is patched before the announcement, or patched along with the announcement. The overwhelming majority of the announcements I see are XSS and SQL injections against web frameworks -- or various ways of re-verbing existing problems with new buzzwords. As far as "what exact % of the time" that is impossible to determine until you at the very least put a threshold on the severity of a security issue. And when it comes to some issues, frankly what some people consider a needed feature another may consider a security hole. Take FTP and Telnet, for example. "Holy crap, wotmud.org:2222 is WIDE OPEN to incoming telnet requests!" would be a ridiculous thing to proclaim, but I've seen it done. I've also seen people say "Ubuntu is WIDE OPEN because they have a new guest account by default with a consistent name!" -- as if names were equivalent to passwords.