Uptime vs. Kernel updates (was Re: [TriLUG] Prosperous New Year)

[jonc]

On Wed, 2006-01-04 at 12:31, Mike Johnson wrote:
> Jon Carnes wrote:
> > I don't like to apply kernel updates unless it's for a vulnerability
> > that makes the machine accessible to an outsider. Over the past couple
> > of years I haven't seen one that allows an outsider to hack into my box
> > - though there have been a few that allow a local user to gain root.
> > Fortunately, I'm the only user on my Linux servers - and I *already*
> > have root access... so no biggie.
> > 
> > It's not the greatest systems philosophy - and not one I would apply if
> > I were working for someone besides myself. But it works for me. If I'm
> > wrong, I'm sure my Trilug buds will give me the slap down that I
> > deserve!
> 
> Well, I can't pass up that challenge, now can I? ;)
> 
> The majority of kernel vulnerabilities allow for user privilege 
> escalation.  This means, as stated, one has to already be a user to be 
> able to exploit the vulnerability.  However, this turns could allow an 
> attacker to gain privileges that would have been otherwise limited.  For 
> instance, exploiting a vulnerability in most network daemons (opensshd, 
> sendmail, postfix, apache, etc) would grant, at most, the rights of that 
> user.  So, say there's an unpatched vulnerability in apache.  Were an 
> attacker to exploit the vulnerability and gain the ability to execute 
> arbitrary code, they can only execute said code as the user of the 
> webserver (nobody, httpd, www-user, etc).  Now, if that code were a 
> kernel exploit, they now have root privileges.
> 
> The steps would look like this:
> 1) Exploit vulnerability in apache
> 2) Exploit code downloads additional program and invokes it
> 3) New program exploits kernel vulnerability and is now running as root
> 4) New program binds a bash shell to port 22222
> 5) Attacker points netcat at port 22222 and is greeted with a # prompt
> 
> As an aside, if you don't reboot your system until you absolutely have 
> to, how do you know that when you -do- reboot it, there will be no 
> problems?  Put another way, rebooting during a maintenance window 
> ensures that when you have an emergency reboot, the system will return 
> to a running state.
> 
> Mike

Mike, you wily old goat, Good Points!

The other reason I don't like to reboot the mail server or firewall is
that each is set to take over for the other should one go down. The mail
server has built-in firewalling and will take over the IP of the
unresponsive firewall box... and the firewall box will do the same for
the mail server (with Postfix on stand-by).

I've tested them and it works great, plus they are using a standard set
of fail-over scripts that I've been using for years. 

When I do a systems upgrade next year I will be replacing each of those
units with brand new servers. At that time the old ones will be
re-assigned to simply be fail-over backup's for their replacements. So I
won't be using cross-purpose machines for fail-over/backup, and I'll
feel more comfortable in rebooting them for a whim.

Till then, uptime is king!

Jon 

BTW: I *do* keep them updated for Apache, Postfix, and any other
application that I run on the servers - so for the above scenario to
work, they would have to exploit an unknown vulnerability in apache...

Still it's better to have multiple layers of security... and I do. MSEC
runs in paranoid mode on that box and prevents *any* change to apache -
or any other app. I have to drop MSEC to upgrade the apps, then bring
MSEC online and have it rescan the box. Man, I love that MSEC!