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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
