[CentOS] what percent of time are there unpatched exploits against default config?

Wed Dec 28 08:56:06 UTC 2011
夜神 岩男 <supergiantpotato at yahoo.co.jp>

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.