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

[Bennett Haselton]

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?

Bennett

2011/12/27 夜神 岩男 <supergiantpotato at yahoo.co.jp>

> On 12/28/2011 01:29 PM, Bennett Haselton wrote:
> > On Tue, Dec 27, 2011 at 8:33 PM, Gilbert Sebenste<
> > sebenste at weather.admin.niu.edu>  wrote:
> >
> >> On Tue, 27 Dec 2011, Bennett Haselton wrote:
> >>
> >>> Suppose I have a CentOS 5.7 machine running the default Apache with no
> >>> extra modules enabled, and with the "yum-updatesd" service running to
> >> pull
> >>> down and install updates as soon as they become available from the
> >>> repository.
> >>>
> >>> So the machine can still be broken into, if there is an unpatched
> exploit
> >>> released in the wild, in the window of time before a patch is released
> >> for
> >>> that update.
> >>>
> >>> Roughly what percent of the time is there such an unpatched exploit in
> >> the
> >>> wild, so that the machine can be hacked by someone keeping up with the
> >>> exploits?  5%?  50%?  95%?
> >>
> >> There's no way to give you an exact number, but let me put it this way:
> >>
> >> If you've disable as much as you can (which by default, most stuff is
> >> disabled, so that's good), and you restart Apache after each update,
> >> your chances of being broken into are better by things like SSH brute
> >> force attacks. There's always a chance someone will get in, but when you
> >> look at the security hole history of Apache, particularly over the past
> >> few years, there have been numerous CVE's, but workarounds and they
> aren't
> >> usually earth-shattering. Very few of them have. The latest version that
> >> ships with 5.7 is as secure as they come. If it wasn't, most web sites
> >> on the Internet would be hacked by now, as most run Apache
> >>
> >
> > I was asking because I had a server that did get broken into, despite
> > having yum-updatesd running and a strong password.  He said that even if
> > you apply all latest updates automatically, there were still windows of
> > time where an exploit in the wild could be used to break into a machine;
> in
> > particular he 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."
> >
> > Was this a sufficiently high-profile incident that you know what he's
> > referring to?  If this kind of thing happens once a year or more, than
> > surely this is a much greater threat than "brute forcing the SSH
> > password"?  That's what I'm talking about -- how often does this sort of
> > thing happen, where you need to be subscribed to be a security mailing
> list
> > in order to know what workaround to make to stay safe, as opposed to
> simply
> > running yum-updatesd to install latest patches automatically.
>
> Nearly every time servers get broken into they are web servers, and web
> servers serving applications the greatest percentage of those. The "web"
> never having been intended as an applications platform provides a huge
> number of attack vectors which are entirely separate from the OS layer.
>
> For example, a perfectly secure operating system running a perfectly
> secure Apache configuration on a perfectly secure MySQL deployment could
> be running an application that permits injection of arbitrary SQL
> commands into the database. The server itself may not be compromised (or
> it may, depending on what else that SQL command can touch/be referenced
> by) in the sense that someone can open a shell, but in most cases there
> is nothing of interest on a web server anyway. What is interesting is
> what is in the database or lives within the application being served,
> and that is an application/database layer problem, not an OS, web-server
> or kernel problem.
>
> With the vast majority of web applications being developed on frameworks
> like Drupal, Django and Plone, the overwhelming majority of "server
> hacks" with regard to the web have to do with attacking these structures
> (at least initially), not the actual OS layer directly at the outset.
>
> Compare this with email server software, which, if the OS layer were the
> inherent problem, would be heard about every day -- much more often than
> web-related cracks. But email server software is mature and just as
> secure as Apache is. However, web-based email is a common target, and
> for a good reason. http is inherently insecure, and bouncing someone
> from http to https is just as insecure because the initial http link and
> DNS can be attacked, both being deliberately insecure, public protocols.
>
> Blah blah. My point is, the OS is rarely attacked directly in
> web-related cracks. A good cracker tries to discover flaws in young,
> fast changing web frameworks which require priviledged access to things
> like MySQL instead of trying to attack Apache or an SE-enabled OS layer
> directly.
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>