check_by_ssh question

[Paul L. Allen]

Andreas Ericsson writes: 

> Yes, and they can later elevate their privileges. Most linux users run one 
> of the major distributions (like Red Hat). I still haven't seen a default 
> Red Hat install without a local root exploit (usable by 'nobody').

I haven't seen anything that doesn't have local exploits.  Most sensible
people apply patches as soon as they come out.  But if you're foolish
and have a monitored machine that has local exploits then it is very
likely your monitoring machine also has the same exploits.  Therefore
you have more important things to fix before you worry about nagios
being used as an exploit.  And if you fix the important things first,
the nagios exploit then can do little damage. 

> Wrong. There are also remote exploits. If you were to follow bugtraq or 
> vuln-dev you wouldn't have that false sense of security.

I don't have a false sense of security, I have a sense of priorities.
Your proposed nagios exploit relies upon far more serious exploits in
order to be able to use it in the first place. 

Your attitude is "Somebody could use an exploit to get root on your
monitoring machine, get shell as nagios on the monitored machine and
then use the same exploit to get root there, so don't use keys with
nagios."  My attitude is "fix exploits as soon as you learn of them." 

> You seem to think that allowing an attacker in as any other user than root 
> is half OK.

I don't think that at all. 

> I don't really understand where you came up with the idea that there
> are no local privilege escalation problems,

There will always be local privilege escalation problems.  All you can
do is fix them as soon as possible.  The point is that if you have a
local exploit that you leave unfixed then you have far more to worry
about than a nagios exploit. 

> but I'd never hire you to run a network I was depending on.

The feeling is mutual.  NONE of our machines that perform network services
have local users who do not already know the root password because the
only users on those machines are those tasked with administering them.
Those people may choose bad pasawords but we make damned sure root has
a strong password and administrators can only get onto the machine locally
or by ssh  So if an attacker gets root on our monitoring machine it has to
be through a remote exploit and therefore all our monitored machines are
likely to have the same vulnerability so the nagios exploit is not needed. 

Like I said, I have s sense of priorities.  Anyone who can use the nagios
exploit already has a remote exploit that they can use instead. 

> If you have plugins running as root (either sudo or +s), you're trying too 
> hard. If you have kernel patches in place to disallow access to regular 
> users to certain items, it's NOT recommended to bypass these with sudo and 
> +s.

There have to be compromises between security and utility.  I can make
any machine 100% safe from network attacks by unplugging it from the
network.  But I'd be interested in seeing your kernel patch to allow
the check_raid plugin function without sudo. 

> Or, they could hack root using a local exploit on any of the machines in 
> the network. Please don't tell me you're immune, or that you have really 
> good security.

The only way somebody can do that to us is if they use a remote exploit to
get into the monitoring machine.  If they can do that then they can use
the SAME remote exploit to get into the monitored machines.  If they can
somehow get shell as nagios on the monitoring machine but cannot use that
with a local exploit to get root then they can't do much on the monitored
machines either.  In that situation, trying to prevent them from using the
nagios exploit is a pointless waste of time because they either have
a remote root exploit or they cannot use nagios to get root.  The only
way they can use the nagios exploit to do damage on the remote machines
is if they already have a way of doing damage without it. 

> With shadow passwords there are a bunch of setsuid programs on the 
> machine, some of which may allow local privilege escalation.

There are always local exploits.  Which is one reason why none of our
network machines have ordinary users who do not also know the root
password.  We don't mix the concepts of "server" and "user machine" and
I wouldn't trust anyone who did. 

> Is he running Nagios at home? Monitoring your business network?

Yes, because the office is in a building at the bottom of his garden.
He looked at the cost of a leased line and couldn't justify it.  Fixed
IP here is EXPENSIVE. 

> Now I understand where your security thinking gets warped.

Yes, I'm an engineer.  That means cost is an important part of my
thinking.  So I don't pay for fixed IP if I can work around it.  So I
don't waste time fixing the nagios exploit when the only way somebody
could use it means either that they already have a remote exploit they
can use or they can't do any damage with it. 

> Also, any admin on customer-network1 could submit passive check results 
> for customer-network2.

I already mentioned that.  First, of course, they have to know that the
other customer exists and what we've called their servers in Nagios. 

>> I can't think of a reason why anyone would want to do this, but they 
>> could.
> I can't think of a reason for people to send spam, or run DoS attacks on 
> home users, but they do anyway.

OK, so somebody at customer1 gets the root password for their local
nagios machine sending passive service checks to us.  That means they've
hijacked a machine we supply and control and can do more damage than
submitting fake checks.  Then they somehow guess what other customers
we monitor and what we've called their machines.  Then they start
submitting fake service checks.  If they do it from a machine that's
traceable, the Computer Misuse Act means up to five years in prison.  If
they happen to have a distributed attack network, they cannot be easily
traced but they can do far more damage to us with a DDoS anyway. 

There's no point patching a pin-hole leak near the top of a bucket when
the bottom has dropped out of the bucket.  If somebody can send fake
passive checks that means I have bigger problems to worry about first.
In an ideal world, NCSA would allow different usernames/passwords so
that tiny risk of somebody submitting fake results is no longer there,
which is why I suggested it would be a useful feature. 

>> But if you really felt an urge to start hacking around, I'd like to
>> see NCSA take an optional username and the daemon take a list of
>> username/password pairs.
> Rather an IP/password pair, for obvious reasons.

Nope, username/password pairs.  Many of the machines we monitor are on
cable or DSL and do not have fixed IP.  Fixed IP is EXPENSIVE here and
many people are unwilling to pay for it.  If you want to block by IP
you can use TCPwrappers.  Making it IP/password restricts utility and
adds no security that cannot be achieved another way. 

>> Then each client could have a different username
>> and password and the only (slight, improbable) security hole in NCSA
>> would be plugged without having to run multiple daemons.
> Unless we start thinking about buffer overflows, integer overflows, 
> off-by-one bugs and other 'useful' (if you're looking to hack it) stuff, 
> but I suppose you've browsed the source for it and decided there are no 
> such faults in it.

I suppose you've gone through the source of the entire kernel and every
utility and application on your machines.  I expect you've paid particular
attention to apache, bind, postfix/sendmail/qmail, sshd, etc.  More
realistically, such bugs will always be with us and all we can do is
hope that if somebody finds a remote exploit they use it against somebody
else first and a patch appears that we can apply before they get around to
using it against us.  It isn't feasible to check the sources of everything
that is installed on a server.  And you do have to check the sources to
EVERYTHING.  Not to mention disassembling gcc to ensure it doesn't have
Ken Thompson's famous back-door (I think he was joking, but it's possible
every *nix machine has a back-door that Ken can use to get in). 

-- 
Paul Allen
Softflare Support 




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null